On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
It might be better to discuss this on the developers mailing list (instead of sending it to everyone in the inkscape developers group).
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action:
1. Detect version of Inkscape that file was saved with and automatically convert linked offsets.
2. Supply an extension that can "fix" linked offsets from older versions.
3. Provide details for manual migration (what's the easiest way to get people's linked offsets to behave like they used to).
4. Make the behaviour optional (per file), possibly in combination with version detection.
5. Create a new way to achieve linked offsets so that it does not affect old linked offsets.
Personally I'm not a big fan of 4 (extra code, extra complication). Option 1 is kind of nice in some cases, but in this particular setting it could prove to be a hassle if files move between people with different versions. All in all I would recommend option 2 or 3, and possibly 5, if you're feeling adventurous :)
Option 5 is probably a bit more involved, but would be cool. In particular, I was thinking that it might be cool to be able to use LPEs on "clones", and a linked offset would then just be a certain kind of LPE. Currently this isn't possible as clones are not paths, so it would probably require creating a new kind of "linked path" and making sure that LPEs work with that. Then we would need to create an LPE that does an offset and make sure that the offset can be edited on canvas.
With option 5 we could choose to keep the old linked offsets code around or to remove it. The latter has the advantage that existing files will still render correctly, any old-style linked offsets simply aren't editable as linked offsets anymore.
Hello,
I would recoomend to stick to the standard rather old code behaviour. So an "automatic" conversion of old type to new type on load makes absolute sense.
For me working as user I would appreciate if I do not have to set options, execute extensions etc. it should run in automaticaly background. (maybe a popup: "you file has been converted to inkscape version 0.48")
my 2ct. I wrote this without digging into the details and looking what is possible or not.
Adib.
On Fri, Aug 26, 2011 at 9:54 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
It might be better to discuss this on the developers mailing list (instead of sending it to everyone in the inkscape developers group).
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action:
- Detect version of Inkscape that file was saved with and automatically
convert linked offsets.
Supply an extension that can "fix" linked offsets from older versions.
Provide details for manual migration (what's the easiest way to get
people's linked offsets to behave like they used to).
- Make the behaviour optional (per file), possibly in combination with
version detection.
- Create a new way to achieve linked offsets so that it does not affect
old linked offsets.
Personally I'm not a big fan of 4 (extra code, extra complication). Option 1 is kind of nice in some cases, but in this particular setting it could prove to be a hassle if files move between people with different versions. All in all I would recommend option 2 or 3, and possibly 5, if you're feeling adventurous :)
Option 5 is probably a bit more involved, but would be cool. In particular, I was thinking that it might be cool to be able to use LPEs on "clones", and a linked offset would then just be a certain kind of LPE. Currently this isn't possible as clones are not paths, so it would probably require creating a new kind of "linked path" and making sure that LPEs work with that. Then we would need to create an LPE that does an offset and make sure that the offset can be edited on canvas.
With option 5 we could choose to keep the old linked offsets code around or to remove it. The latter has the advantage that existing files will still render correctly, any old-style linked offsets simply aren't editable as linked offsets anymore.
EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
On Fri, 2011-08-26 at 14:08 +0200, the Adib wrote:
Hello,
I would recoomend to stick to the standard rather old code behaviour. So an "automatic" conversion of old type to new type on load makes absolute sense.
Automatic conversion, unfortunatelly, will result in a forward compatibility problem.
Linked offsets, I think, are not defined in the svg standard but, rather, are implementation specific to inkscape that are saved as svg defined elements and inkscape-defined ones (ie not editable as linked offsets in any other program)
For me working as user I would appreciate if I do not have to set options, execute extensions etc. it should run in automaticaly background. (maybe a popup: "you file has been converted to inkscape version 0.48")
This might be intresting, but if the user decides to not do the conversion? should we mark it as uneditable and revert to the old rendering? (editing is extremelly difficult to implement with these different behaviors coexisting)
my 2ct. I wrote this without digging into the details and looking what is possible or not.
Adib.
On Fri, Aug 26, 2011 at 9:54 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
It might be better to discuss this on the developers mailing list (instead of sending it to everyone in the inkscape developers group).
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action:
- Detect version of Inkscape that file was saved with and automatically
convert linked offsets.
Supply an extension that can "fix" linked offsets from older versions.
Provide details for manual migration (what's the easiest way to get
people's linked offsets to behave like they used to).
- Make the behaviour optional (per file), possibly in combination with
version detection.
- Create a new way to achieve linked offsets so that it does not affect
old linked offsets.
Personally I'm not a big fan of 4 (extra code, extra complication). Option 1 is kind of nice in some cases, but in this particular setting it could prove to be a hassle if files move between people with different versions. All in all I would recommend option 2 or 3, and possibly 5, if you're feeling adventurous :)
Option 5 is probably a bit more involved, but would be cool. In particular, I was thinking that it might be cool to be able to use LPEs on "clones", and a linked offset would then just be a certain kind of LPE. Currently this isn't possible as clones are not paths, so it would probably require creating a new kind of "linked path" and making sure that LPEs work with that. Then we would need to create an LPE that does an offset and make sure that the offset can be edited on canvas.
With option 5 we could choose to keep the old linked offsets code around or to remove it. The latter has the advantage that existing files will still render correctly, any old-style linked offsets simply aren't editable as linked offsets anymore.
EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks
Adonis
On Fri, Aug 26, 2011 at 9:03 AM, Adonis Papaderos <ado.papas@...1244...> wrote:
For me working as user I would appreciate if I do not have to set options, execute extensions etc. it should run in automaticaly background. (maybe a popup: "you file has been converted to inkscape version 0.48")
This might be intresting, but if the user decides to not do the conversion? should we mark it as uneditable and revert to the old rendering? (editing is extremelly difficult to implement with these different behaviors coexisting)
Illustrator 13 pops up a dialog upon opening version 14 or newer files that is basically "Import or Cancel". This works fine for me because:
A - the conversion works >90% of the time B - I *know* that something might have been altered, so also I know that I should inspect the drawing carefully
Not that Illustrator is my favorite program - just thought I'd throw that out there since IMO they took a decent approach to the forward-compatibility problem ;) I'm all for automatically converting as long as it's clear that something has been changed, and the file is marked 'dirty'.
Chris
2011/8/26 Adonis Papaderos <ado.papas@...1244...>:
On Fri, 2011-08-26 at 14:08 +0200, the Adib wrote:
Hello,
I would recoomend to stick to the standard rather old code behaviour. So an "automatic" conversion of old type to new type on load makes absolute sense.
Automatic conversion, unfortunatelly, will result in a forward compatibility problem.
There's a simple solution: write the new offset XML in such a way that old Inkscape versions will detect them as normal paths. It can be done using e.g. svg:switch, or a magic path type. Old version will lose some editing capabilities, but we only have to maintain a one-way conversion.
We have to do the same with guides and 3D boxes. Old guides store their anchor point in desktop coordinates. We can just change all sodipodi:guideline to inkscape:guideline when loading - old Inkscapes will ignore those elements while new ones will display it correctly.
Regards, Krzysztof
Hello,
On Fri, 2011-08-26 at 22:09 +0200, Krzysztof Kosiński wrote:
2011/8/26 Adonis Papaderos <ado.papas@...1244...>:
On Fri, 2011-08-26 at 14:08 +0200, the Adib wrote:
Hello,
I would recoomend to stick to the standard rather old code behaviour. So an "automatic" conversion of old type to new type on load makes absolute sense.
Automatic conversion, unfortunatelly, will result in a forward compatibility problem.
There's a simple solution: write the new offset XML in such a way that old Inkscape versions will detect them as normal paths.
sounds good to me. maybe inkscape:linked_offset
It can be done using e.g. svg:switch, or a magic path type.
svg:switch seems to have strictry defined attributes. (offtopic: what is a magic path type?)
Old version will lose some editing capabilities, but we only have to maintain a one-way conversion.
We have to do the same with guides and 3D boxes. Old guides store their anchor point in desktop coordinates. We can just change all sodipodi:guideline to inkscape:guideline when loading - old Inkscapes will ignore those elements while new ones will display it correctly.
Regards, Krzysztof
thanks,
adonis
W dniu 26 sierpnia 2011 22:29 użytkownik Adonis Papaderos <ado.papas@...1244...> napisał:
sounds good to me. maybe inkscape:linked_offset
Better use hyphens instead of underscores: inkscape:linked-offset
It can be done using e.g. svg:switch, or a magic path type.
svg:switch seems to have strictry defined attributes. (offtopic: what is a magic path type?)
I'm not 100% sure, but I think that by default an user agent is required to show the first child element it understands. The attributes can be used to change this default choice of the element.
"Magic path type" is a special attribute on svg:path used to create a different SPObject for it, as an easier but less flexible substitute for svg:switch. This is used for example for ellipses.
Regads, Krzysztof
Hello,
Imagine that a user makes a linked offset to an object using .48 version opening it with current develompent and then reopening it with .48 and editing the offset (now a path).
If the user reopens the file with current development version, the path data will get recalculated from the original, thus the changes he did with the .48 version get lost.
Any ideas how this could get resolved?
On Fri, 2011-08-26 at 23:04 +0200, Krzysztof Kosiński wrote:
W dniu 26 sierpnia 2011 22:29 użytkownik Adonis Papaderos <ado.papas@...1244...> napisał:
sounds good to me. maybe inkscape:linked_offset
Better use hyphens instead of underscores: inkscape:linked-offset
It can be done using e.g. svg:switch, or a magic path type.
svg:switch seems to have strictry defined attributes. (offtopic: what is a magic path type?)
I'm not 100% sure, but I think that by default an user agent is required to show the first child element it understands. The attributes can be used to change this default choice of the element.
"Magic path type" is a special attribute on svg:path used to create a different SPObject for it, as an easier but less flexible substitute for svg:switch. This is used for example for ellipses.
Regads, Krzysztof
Thanks,
Adonis.
2011/8/27 Adonis Papaderos <ado.papas@...1244...>
Any ideas how this could get resolved?
This has already been discussed before, you can read this thread (april 2010): [Inkscape-devel] Document versioning (was: Coordinate system fix))
http://sourceforge.net/mailarchive/message.php?msg_id=24953667
On Fri, 2011-08-26 at 09:54 +0200, Jasper van de Gronde wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
It might be better to discuss this on the developers mailing list (instead of sending it to everyone in the inkscape developers group).
My bad. I thought launchpad would take care of it. Thanks for fixing it.
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action:
- Detect version of Inkscape that file was saved with and automatically
convert linked offsets.
Supply an extension that can "fix" linked offsets from older versions.
Provide details for manual migration (what's the easiest way to get
people's linked offsets to behave like they used to).
- Make the behaviour optional (per file), possibly in combination with
version detection.
- Create a new way to achieve linked offsets so that it does not affect
old linked offsets.
Personally I'm not a big fan of 4 (extra code, extra complication). Option 1 is kind of nice in some cases, but in this particular setting it could prove to be a hassle if files move between people with different versions. All in all I would recommend option 2 or 3, and possibly 5, if you're feeling adventurous :)
I aggree. Option 1 is the same situation we have now, but in reverse.
Option 2 could easily result to be the same as option 1, as it is an one way migration.
Option 3 is not going to be easy as users would have to perform matrix calculations.
Option 4 would probably make the code too complicated, as the offset code is highly coupled with the offset manipulation code.
Option 5 is probably a bit more involved, but would be cool. In particular, I was thinking that it might be cool to be able to use LPEs on "clones", and a linked offset would then just be a certain kind of LPE. Currently this isn't possible as clones are not paths, so it would probably require creating a new kind of "linked path" and making sure that LPEs work with that. Then we would need to create an LPE that does an offset and make sure that the offset can be edited on canvas.
Indeed, this would be cool. I was thinking, at the time, of a notion of "live clones" or "references", but the events I could get out of transformations of the original objects were too disperse to implement it (ie with some objects i would get a transformation event, with some others an object modification event). Also I had problems with the events fired by the undo and redo functionality.
Making live effects editable on canvas would be very nice indeed, but I have not seen it done yet, so I don't know if it is feasible.
I am affraid that if we try to take this road with the current state of events, we will end up in the same situation (even worse) that the new elements are going to be extremelly slow to manipulate since we will have to calculate this type of effects many times a second.
With option 5 we could choose to keep the old linked offsets code around or to remove it. The latter has the advantage that existing files will still render correctly, any old-style linked offsets simply aren't editable as linked offsets anymore.
Since I believe that, in the long run, option 5 will be the way to go (I think i listened to someone from w3c in a presentation that he thought the lack of a well defined refereces should be addressed with the next version of svg), probably the most practical solution to this is to revert to the old behavior and either start implementing our way to fully working references, or wait to see if and how references will be addressed with the next version of svg.
Thnaks
Adonis
---- Adonis Papaderos <ado.papas@...1244...> wrote:
On Fri, 2011-08-26 at 09:54 +0200, Jasper van de Gronde wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
Obviously going with the "new and improved" behaviour will cause some problems with existing material, but I'm afraid it's impossible to always avoid this. Now, if you want to be really friendly towards people with existing material there are a couple of possible courses of action:
- Detect version of Inkscape that file was saved with and automatically
convert linked offsets.
Note: this is what Inkscape does if it finds pre-0.46 definition of a grid.
[...]
Making live effects editable on canvas would be very nice indeed, but I have not seen it done yet, so I don't know if it is feasible.
Off-topic, but, ...??!?!?!?!? ;) (it's hard to even remember LPEs *not* being live-editable on canvas)
-Johan
On Fri, Aug 26, 2011 at 8:35 AM, <jbc.engelen@...2592...> wrote:
Off-topic, but, ...??!?!?!?!? ;) (it's hard to even remember LPEs *not* being live-editable on canvas)
Maybe it's in reference to some being only partially editable on canvas at any given time? Envelope is an example where you you have 4 control paths, but need to actually toggle between them rather than them being all available all the time. I could be mistaken.
As an aside though, it could be a reference to how GIMP now does on-canvas text editing (in their development branch). http://libregraphicsworld.org/articles.php?article_id=34 If you scroll down to the on-canvas text part, note the floating panel which is available when you click into a text item. It's really a usability win (imho) over our approach with the tool controls bar or docked dialogs.
If an object has LPEs applied, how wicked would it be to have the control right next to the object? Note, the usability win is imho minimal mouse movement and making the proper editing tools more "obvious".
Cheers, Josh
On Fri, Aug 26, 2011 at 7:54 PM, Josh Andler wrote:
As an aside though, it could be a reference to how GIMP now does on-canvas text editing (in their development branch). http://libregraphicsworld.org/articles.php?article_id=34 If you scroll down to the on-canvas text part, note the floating panel which is available when you click into a text item. It's really a usability win (imho) over our approach with the tool controls bar or docked dialogs.
If an object has LPEs applied, how wicked would it be to have the control right next to the object? Note, the usability win is imho minimal mouse movement and making the proper editing tools more "obvious".
Just a minor observation... Currently we have a wicked system of spitting out LPE controls as is. If we do that on canvas, that is going to be a dozen of *our* generations damned by our beloved user base :) Just think about it: we'll probably have intestellar traveling by the time, and in that age of great wisdom and eternal friendship with extraterrestrial races our descendants will suffer from early 21st century superstitions caused by our wrongdoing :)
So before we go canvas, it's be jolly cool to figure out which controls could go and which controls could get in-place numeric input. And how that in-place numeric editing would work.
Alexandre Prokoudine http://libregraphicsworld.org
On Fri, Aug 26, 2011 at 9:13 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Fri, Aug 26, 2011 at 7:54 PM, Josh Andler wrote:
As an aside though, it could be a reference to how GIMP now does on-canvas text editing (in their development branch). http://libregraphicsworld.org/articles.php?article_id=34 If you scroll down to the on-canvas text part, note the floating panel which is available when you click into a text item. It's really a usability win (imho) over our approach with the tool controls bar or docked dialogs.
If an object has LPEs applied, how wicked would it be to have the control right next to the object? Note, the usability win is imho minimal mouse movement and making the proper editing tools more "obvious".
Just a minor observation... Currently we have a wicked system of spitting out LPE controls as is. If we do that on canvas, that is going to be a dozen of *our* generations damned by our beloved user base :) Just think about it: we'll probably have intestellar traveling by the time, and in that age of great wisdom and eternal friendship with extraterrestrial races our descendants will suffer from early 21st century superstitions caused by our wrongdoing :)
So before we go canvas, it's be jolly cool to figure out which controls could go and which controls could get in-place numeric input. And how that in-place numeric editing would work.
Nothing beats getting a random thought nuked. :) For the record, I wasn't thinking we should take action or that it's the best solution... just suggesting that we start imagining more UI-wise, but I can see where I wasn't particularly clear about that.
It boils down to, I think that they're actually doing some interesting things UI-wise with The GIMP that we should take note of. Test them out in their sandbox, read user and tester feedback about them, and see if they're worth adapting for our needs. I don't think all controls for all tools/features belong on canvas, but for text, personally, I really like what they've done. Maybe I just like it so much because the text tool in gimp actually feels usable to me now. It's definitely at least partially subjective in this case.
Oh, and for the record, the first place I'd want to see additional on-canvas controls is filters, Being able to naturally click-drag a blur on an object or move the light sources would be a big win imho (vs numeric input/dialog controls). That also would be easily achieved as it's similar to existing on-canvas controls we have.
Cheers, Josh
On Fri, Aug 26, 2011 at 8:31 PM, Josh Andler wrote:
Oh, and for the record, the first place I'd want to see additional on-canvas controls is filters, Being able to naturally click-drag a blur on an object or move the light sources would be a big win imho (vs numeric input/dialog controls). That also would be easily achieved as it's similar to existing on-canvas controls we have.
I'm 100% with you there. However there go the problems:
1. You can't really have a slider for something that doesn't have a finite amount.
2. We do not provide a human reeadable abstraction from SVG guts. Some of the filter primitives settings have a prerequisite of PhD in digital imaging. In an ideal world everybody shares the knowledge of Ivan Louette, but... :)
OTOH I do agree about moving filter stuff on canvas. Demos of the new compositor in Blender make me drool all over the floor.
Oh, and I do agree about text options on canvas. Except that means we seriusly review our use of the tools options toolbar.
Alexandre Prokoudine http://libregraphicsworld.org
To move filters controls to canvas you need to know which filter primitive and which part of this primitive you want activate,or which option (for example for Blend which has no numeric entries or for Composite which has numeric entries only for one of its multiple options.
ivan
________________________________ De : Alexandre Prokoudine <alexandre.prokoudine@...400...> À : Inkscape Devel List inkscape-devel@lists.sourceforge.net Envoyé le : Vendredi 26 Août 2011 18h44 Objet : Re: [Inkscape-devel] linked offsets
On Fri, Aug 26, 2011 at 8:31 PM, Josh Andler wrote:
Oh, and for the record, the first place I'd want to see additional on-canvas controls is filters, Being able to naturally click-drag a blur on an object or move the light sources would be a big win imho (vs numeric input/dialog controls). That also would be easily achieved as it's similar to existing on-canvas controls we have.
I'm 100% with you there. However there go the problems:
1. You can't really have a slider for something that doesn't have a finite amount.
2. We do not provide a human reeadable abstraction from SVG guts. Some of the filter primitives settings have a prerequisite of PhD in digital imaging. In an ideal world everybody shares the knowledge of Ivan Louette, but... :)
OTOH I do agree about moving filter stuff on canvas. Demos of the new compositor in Blender make me drool all over the floor.
Oh, and I do agree about text options on canvas. Except that means we seriusly review our use of the tools options toolbar.
Alexandre Prokoudine http://libregraphicsworld.org
------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Daz Studio - free - has nice sliders for unknown quantities. Uses Qt adds aspects like a rate based change and auto recentering of the slider value on release.
On 8/31/2011 5:24 PM, Jon Cruz wrote:
On Aug 26, 2011, at 9:44 AM, Alexandre Prokoudine wrote:
- You can't really have a slider for something that doesn't have a
finite amount.
Sure you can.
It just takes a little use-case and UI magic.
And a whole lot of thought and research.
Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 26/8/11 09:54, Jasper van de Gronde wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
Just to make sure I do not misunderstand the issue discussed here: did you mean to say "the work I have done with linked offsets to make them behave as clones"? i.e. (among others) addressing this one:
Bug #184341 https://bugs.launchpad.net/inkscape/+bug/184341 "Linked offsets ignore clone movement preferences"
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
With regard to the changes for bug #184341 I'd be curious to understand _why_ the changed behavior of linked offsets is an improvement and why the old behavior "doesn't make much sense"? [1]
AFAIU linked offsets and clones have different use cases:
Linked Offsets: a Inkscape-specific path operation along with inset/outset and dynamic offset, linking to a single path, often used to create multiple borders (stroke effects) of individual objects, shapes or texts - intended to keep the relative position to the original (stacked below or above, maybe slightly offset for shading effects). Linked offsets moves along with the original (as per default setting) and can be styled independently (unlike clones). [2]
Clones: far more powerful SVG feature which can instantiate a variety of (template) objects in the same file, and hopefully - some day - Inkscape will add the support to link to (to clone) fragments of external files (for parts libraries, stencils, shared objects). Clones allow e.g. style variations based in inherited styles while keeping the file size low and updates to common features easy. Clones are not as strongly related to the position of the original object and are often intended to stay in place when the original gets moved (as per default setting).
Changing the default for the setting "When the original moves, ..." for linked offsets and merging it into the behavior of clones could easily result in a new RFE to autogroup linked offset and original for easier handling: for many users it might not be an option to switch back to the old behavior in the preferences since they use clones as instances (not like offsets stacked below/above the cloned shape) and do not want clones to move when an original is rearranged or moved e.g. outside the page border for easier editing or for hiding.
Related questions: - Could the other issues with incorrect handling of (parent) transforms which had been addressed in the merge of r10109 be fixed without changing the default behavior of linked offsets when the original moves, or - alternatively - have linked offsets use separate options with regard to "When the original moves"? [3]
- If none of the above is feasible, what will be the explanation to users for changing the default behavior of linked offsets to no longer follow when moving the original?
~suv
[1] I'm aware that originally it was planned to have them share the same options as clones (as witnessed in the preferences pane). However, for some reason this was never fully implemented, and the same question in the bug report was not answered beyond referring to the labels in the preferences pane:
Ryan Lerch (ryanlerch) wrote on 2008-02-04:
However, im not sure of how that setting in the inkscape pref's is worded. from my experience i would want clones to stay unmoved, but linked offsets to move...
[2] The tutorial which ships with Inkscape explains linked offsets thus:
Still more convenient is a linked offset, which is similar to the dynamic variety but is connected to another path which remains editable. You can have any number of linked offsets for one source path. Below, the source path is red, one offset linked to it has black stroke and no fill, the other has black fill and no stroke.
Select the red object and node-edit it; watch how both linked offsets respond. Now select any of the offsets and drag its handle to adjust the offset radius. Finally, note how moving or transforming the source moves all offset objects linked to it, and how you can move or transform the offset objects independently without losing their connection with the source.
[3] the merged branch had addressed these bugs: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10109
Bug #167419 https://bugs.launchpad.net/inkscape/+bug/167419 "square/circle/polygon/spiral and linked offset misbehaviours"
Bug #184341 https://bugs.launchpad.net/inkscape/+bug/184341 "Linked offsets ignore clone movement preferences"
Bug #239430 https://bugs.launchpad.net/inkscape/+bug/239430 linked offset ungroup issue
On Sat, 2011-08-27 at 11:43 +0200, ~suv wrote:
On 26/8/11 09:54, Jasper van de Gronde wrote:
On 25-08-11 21:51, Adonis Papaderos wrote:
It apears that the work I have done with linked offsets to make them behave as linked offsets have the side-effect of breaking compatibility with old drawings that rely on the old behavior. (see bug #817907 https://bugs.launchpad.net/inkscape/+bug/817907). I believe that commit 10109 should be revoked and the attached bugs marked as won't fix (since I don't see any other way of fixing these).
What do you think?
Just to make sure I do not misunderstand the issue discussed here: did you mean to say "the work I have done with linked offsets to make them behave as clones"? i.e. (among others) addressing this one:
Bug #184341 https://bugs.launchpad.net/inkscape/+bug/184341 "Linked offsets ignore clone movement preferences"
yes
As for your question, as far as I can tell it's choosing between sticking to old behaviour that doesn't make much sense and causes problems for at least some people and new behaviour that makes a lot more sense but might cause some problems for existing drawings. This is not an easy choice, but I would be inclined to go with the new behaviour, as that's probably the better choice in the long run.
With regard to the changes for bug #184341 I'd be curious to understand _why_ the changed behavior of linked offsets is an improvement and why the old behavior "doesn't make much sense"? [1]
The behavior is not "exactly" changed. As I understood, the code was written without taking into account the optimized transformations. When optimized transformations were not enabled, linked offsets respected the preferences of the cloned objects. When optimized transformations were enabled, though, some did, some didn't.
AFAIU linked offsets and clones have different use cases:
Linked Offsets: a Inkscape-specific path operation along with inset/outset and dynamic offset, linking to a single path, often used to create multiple borders (stroke effects) of individual objects, shapes or texts - intended to keep the relative position to the original (stacked below or above, maybe slightly offset for shading effects). Linked offsets moves along with the original (as per default setting) and can be styled independently (unlike clones). [2]
Clones: far more powerful SVG feature which can instantiate a variety of (template) objects in the same file, and hopefully - some day - Inkscape will add the support to link to (to clone) fragments of external files (for parts libraries, stencils, shared objects). Clones allow e.g. style variations based in inherited styles while keeping the file size low and updates to common features easy. Clones are not as strongly related to the position of the original object and are often intended to stay in place when the original gets moved (as per default setting).
I'm affraid it was not a consistant behavior as I explained earlier. I am not saying that the way you describe it doesn't make more sense.
Changing the default for the setting "When the original moves, ..." for linked offsets and merging it into the behavior of clones could easily result in a new RFE to autogroup linked offset and original for easier handling: for many users it might not be an option to switch back to the old behavior in the preferences since they use clones as instances (not like offsets stacked below/above the cloned shape) and do not want clones to move when an original is rearranged or moved e.g. outside the page border for easier editing or for hiding.
Related questions:
- Could the other issues with incorrect handling of (parent) transforms
which had been addressed in the merge of r10109 be fixed without changing the default behavior of linked offsets when the original moves, or - alternatively - have linked offsets use separate options with regard to "When the original moves"? [3]
The reason that this recession occured is that the transformation of the original object is now taken into account in the rendering of the offset. We can change the handling of the offsets, but still this problem will still exits.
- If none of the above is feasible, what will be the explanation to
users for changing the default behavior of linked offsets to no longer follow when moving the original?
~suv
[1] I'm aware that originally it was planned to have them share the same options as clones (as witnessed in the preferences pane). However, for some reason this was never fully implemented, and the same question in the bug report was not answered beyond referring to the labels in the preferences pane:
Ryan Lerch (ryanlerch) wrote on 2008-02-04:
However, im not sure of how that setting in the inkscape pref's is worded. from my experience i would want clones to stay unmoved, but linked offsets to move...
[2] The tutorial which ships with Inkscape explains linked offsets thus:
Still more convenient is a linked offset, which is similar to the dynamic variety but is connected to another path which remains editable. You can have any number of linked offsets for one source path. Below, the source path is red, one offset linked to it has black stroke and no fill, the other has black fill and no stroke.
Select the red object and node-edit it; watch how both linked offsets respond. Now select any of the offsets and drag its handle to adjust the offset radius. Finally, note how moving or transforming the source moves all offset objects linked to it, and how you can move or transform the offset objects independently without losing their connection with the source.
[3] the merged branch had addressed these bugs: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10109
Bug #167419 https://bugs.launchpad.net/inkscape/+bug/167419 "square/circle/polygon/spiral and linked offset misbehaviours"
Bug #184341 https://bugs.launchpad.net/inkscape/+bug/184341 "Linked offsets ignore clone movement preferences"
Bug #239430 https://bugs.launchpad.net/inkscape/+bug/239430 linked offset ungroup issue
thanks,
Adonis
participants (13)
-
unknown＠example.com -
Adonis Papaderos -
Alexandre Prokoudine -
Chris Mohler -
Ivan Louette -
Jasper van de Gronde -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Mark Schafer -
the Adib -
Yann Papouin -
~suv