-----Original Message----- From: jf barraud [mailto:jf.barraud@...400...] Sent: Monday, January 12, 2009 14:27 Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
Define a new object attribute where lpe can register a transform (notice this attribute belongs to the objects carrying the lpe, not the lpe itself). These transform represent the "offset transform" between the object and the lpe.
Now, when transforming an object carrying an lpe, the new transform is applied to all transforms in this attribute instead of all the lpe parameters. At render time, the lpe first updates it's parameters according to the relevant transform, and then performs the effect.
-- This solution is very similar to what we're doing now: the difference is only a matter of *when* you transform lpe parameters (on the fly, or at render time). I don't think groups cause more trouble than in all other situations. I think it is a better solution than adding a "transform-lpe" in the stack, like I suggested before.
In any case, just storing the transformation is strange. Because then for some operations the LPE param is not shared, while for other operations it is shared. The param would not be shared when moving the item that has the lpe applied, but the param would be shared when double clicking that item and editing the lpe param. I can give you a very awkward example of lpe hatches when you want shared transforms, hope to show it to you when you are on jabber. But do the calculations and drawings if you have time for not shared transforms, but shared points (so the full param equals point (which is stored in the lpe, hence shared) times transform (which is stored in item hence not shared).
As for user finding shared lpe awkward, you might be right, but this should only affect the default behaviour. Although duplicating (objects, gradients, filters, lpes, others?...) is more straightforward than cloning, having the possibility to clone often makes a huge difference. Think of "styles" for instance, which are a kind of fill/stroke cloning (and unfortunately not supported yet). If sharing does not make sens for some lpes, it does for other, like sketch or pattern along path, which are kind of stroke styles. So shared lpe should not be forbidden a priori. For clarity, we could show the number of users of a given element, and provide buttons to make a clone independant wherever appropriate (in gradients, filters, lpe dialogs).
Shared LPEs are not forbidden. Duplicate an item and you have a shared LPE.
forgot in that discussion is the possibility of always storing the transform matrix in a path with an LPE (it's just a pref setting atm). If people want that, then turn off/on the preference and you're done I think. (prefs -> transforms -> store transf.: preserved)
It's not the same as what I suggest, since different lpe cannot have different transforms.
You mean different LPE in a stack on one item?
Actually there is a very good reason against not propagating the transform to the item at this moment. It is a bug that it is possible to set "store transformations" to preserved for items with LPEs...
Bulia wrote:
I think something like that was planned from the beginning. For example, a true variable width stroke - not just triangle- or ellipse-shaped - would have to store its own set of distance/width pairs, unique for each path.
I think bulia means the data defining the width of the path is path specific. An lpe allowing the user to set the witdth by hand could not be shared, while it could contain also some global parameters we could be interested in sharing (shape of the ends for instance?). The object itself seems to be the right place where to store the object specific width data.
The data defining the width of the path is not necessarily path specific, and it can be very desirable to share that between paths. Take the triangle case, where the width path is something like: 0, 1, 0 with linear interpolation between these 3 values. The width should be specified at locations as function of percentage of total path length, instead of absolute path length. Otherwise, the effect would break easily by "simplifying" (hence removing nodes, hence changing the absolute "length" of a path...). It is exactly this shareability of the path data that makes it possible to predefine some width-shapes that we have now.
Please know that many things that are desired are already possible. Sensibly sharing LPEs is possible, etc. (lpe-hatches and lpe-knot are exceptions).
So what if I want to have some parameter of an effect globally defined, and another locally? And then next week I wake up and want another parameter local, but yet another global? If we make global/local parameters we will also need a toggle for every parameter to make it local/global...
Maybe I'm just sad that my original framework that was easy to read and use has become pretty ugly with all the modifications and very buggy aswell. So I am very reluctant to any other additions. Things are complicated!
(and therefore, this will be my last mail in this topic hopefully. We need to discuss this on jabber where I can explain things in more detail)