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