Hi guys,
what if, as a first step towards 0.47, we clean up the mess in our LPE list - remove proofs of concept, hide those that only make sense in a tool, merge similar ones per our discussion, remove or fix those that crash? Can anyone who's more in the loop please make a list of suggestions?
Hi all, yeah, LPE is a mess :-( I'm sorry I contributed to that :-(
Recently, I improved the conditional compile of unfinished effects. Now, the "test effects" are not compiled, unless one #defines LPE_ENABLE_TEST_EFFECTS. So for example, probably nobody here has the dynamic stroke LPE in their list, while I and jfb have. Have a look in /src/live_effects/effect.cpp around line 80 to see how to hide effects that are not finished.
I am very tempted to move *all* new LPEs since 0.47 to the disabled part. Moreover, every effect should have a test svg that tests the effect in the testsuite; with a couple of not so simple cases of the effect working properly.
cheers, Johan
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: woensdag 7 januari 2009 3:57 To: Inkscape Devel List; Maximilian Albert; Maximilian Albert Subject: [Inkscape-devel] LPE cleanup
Hi guys,
what if, as a first step towards 0.47, we clean up the mess in our LPE list - remove proofs of concept, hide those that only make sense in a tool, merge similar ones per our discussion, remove or fix those that crash? Can anyone who's more in the loop please make a list of suggestions?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Ok, I have an idea: send me an SVG that uses the LPE you want to be present in 0.47 and I'll add that SVG to the testsuite. After three weeks or something, I'll disable all effects that don't have a testfile in the testsuite.
Does that sound reasonable?
LPE is very buggy, now the spiro LPE testfile crashes :-(
-Johan
-----Original Message----- From: J.B.C.Engelen@...1578... [mailto:J.B.C.Engelen@...1578...] Sent: woensdag 7 januari 2009 23:22 To: buliabyak@...400...; inkscape-devel@lists.sourceforge.net; Anhalter42@...173...; maximilian.albert@...1439... Subject: Re: [Inkscape-devel] LPE cleanup
Hi all, yeah, LPE is a mess :-( I'm sorry I contributed to that :-(
Recently, I improved the conditional compile of unfinished effects. Now, the "test effects" are not compiled, unless one #defines LPE_ENABLE_TEST_EFFECTS. So for example, probably nobody here has the dynamic stroke LPE in their list, while I and jfb have. Have a look in /src/live_effects/effect.cpp around line 80 to see how to hide effects that are not finished.
I am very tempted to move *all* new LPEs since 0.47 to the disabled part. Moreover, every effect should have a test svg that tests the effect in the testsuite; with a couple of not so simple cases of the effect working properly.
cheers, Johan
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: woensdag 7 januari 2009 3:57 To: Inkscape Devel List; Maximilian Albert; Maximilian Albert Subject: [Inkscape-devel] LPE cleanup
Hi guys,
what if, as a first step towards 0.47, we clean up the mess
in our LPE
list - remove proofs of concept, hide those that only make
sense in a
tool, merge similar ones per our discussion, remove or fix
those that
crash? Can anyone who's more in the loop please make a list of suggestions?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about
anything
Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Johan,
So for the test files, you want a couple test/examples per file for each effect? Such as a straightforward simple example and then the complex example, correct? Additionally, do you want a couple files utilizing lpe stacking and tests on groups to see if those have breakage again at some point?
It should be quick and straightforward to produce these, so please let me know exactly what you need.
Cheers, Josh
On 01/07/2009 03:41 PM, J.B.C.Engelen@...1578... wrote:
Ok, I have an idea: send me an SVG that uses the LPE you want to be present in 0.47 and I'll add that SVG to the testsuite. After three weeks or something, I'll disable all effects that don't have a testfile in the testsuite.
Does that sound reasonable?
LPE is very buggy, now the spiro LPE testfile crashes :-(
-Johan-----Original Message----- From: J.B.C.Engelen@...1578... [mailto:J.B.C.Engelen@...1578...] Sent: woensdag 7 januari 2009 23:22 To: buliabyak@...400...; inkscape-devel@lists.sourceforge.net; Anhalter42@...173...; maximilian.albert@...1439... Subject: Re: [Inkscape-devel] LPE cleanup
Hi all, yeah, LPE is a mess :-( I'm sorry I contributed to that :-(
Recently, I improved the conditional compile of unfinished effects. Now, the "test effects" are not compiled, unless one #defines LPE_ENABLE_TEST_EFFECTS. So for example, probably nobody here has the dynamic stroke LPE in their list, while I and jfb have. Have a look in /src/live_effects/effect.cpp around line 80 to see how to hide effects that are not finished.
I am very tempted to move *all* new LPEs since 0.47 to the disabled part. Moreover, every effect should have a test svg that tests the effect in the testsuite; with a couple of not so simple cases of the effect working properly.
cheers, Johan
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: woensdag 7 januari 2009 3:57 To: Inkscape Devel List; Maximilian Albert; Maximilian Albert Subject: [Inkscape-devel] LPE cleanup
Hi guys,
what if, as a first step towards 0.47, we clean up the mess
in our LPE
list - remove proofs of concept, hide those that only make
sense in a
tool, merge similar ones per our discussion, remove or fix
those that
crash? Can anyone who's more in the loop please make a list of suggestions?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about
anything
Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-----Original Message----- From: Josh Andler [mailto:scislac@...400...] Sent: donderdag 8 januari 2009 0:18
Johan,
So for the test files, you want a couple test/examples per file for each effect? Such as a straightforward simple example and then the complex example, correct?
Yep. Some effects have quite a bit of options, which should all be tested. Perhaps it is good to test difficult inputs, like closed paths or paths consisting of a number of subpaths.
Additionally, do you want a couple files utilizing lpe stacking and tests on groups to see if those have breakage again at some point?
Good idea :)
It should be quick and straightforward to produce these, so please let me know exactly what you need.
Thanks Josh. You have svn access right? can you put the svgs + reference PNG in the testsuite yourself?
Thnx! Johan
On 01/08/2009 12:24 PM, J.B.C.Engelen@...1578... wrote:
So for the test files, you want a couple test/examples per file for each effect? Such as a straightforward simple example and then the complex example, correct?
Yep. Some effects have quite a bit of options, which should all be tested. Perhaps it is good to test difficult inputs, like closed paths or paths consisting of a number of subpaths.
Okay... will do. My plan then is to do three paths per file, an open one, a closed, and one with a subpath.
It should be quick and straightforward to produce these, so please let me know exactly what you need.
Thanks Josh. You have svn access right? can you put the svgs + reference PNG in the testsuite yourself?
I will check out the other testsuite pairs of files to know what to upload and I will begin sometime soon.
Cheers, Josh
Hi, Good idea! Notice that test failure is not the only reason to set an lpe as experimental however: the definition of parameters and their internal representation are also relevant. With this respect, "hatches" are clearly experimental atm, as the parameter list is very bad...
The tricky case is "knot". it has 2 parameters: the size of the "gaps" and an array storing the "sign" of each crossing (the user can choose which strand is above/below the other, independently for each crossing). The first one is typically global: we can have several knots in the same drawing, and want to have similar "gaps". The second however is typically local: this information only makes sens for one particular path. sharing it among different paths is meaningless.
That is what makes me think lpe should be allowed to register "local" parameters. A new object attribute could be defined (something like "lpe-local-params"), where lpe would register all the data they need. Moreover, I think we'll need this sooner or later to fix the transform issue (lpe cannot be shared atm because the params are transformed along with the object; they'd better stay untransformed, and a local offset transform be stored in each object the effect is applied to...)
So I submit this question to our gurus: is allowing lpe to register "local" parameters a good idea? if yes, is it hard (I'have no idea how to do that)? Btw, if storing local offset transforms instead of transforming parameters is the good way to go, I think I could work on it.
Hm... as for "knot" being experimental or not... I dunno; I'd really like to have it added to the next release (it earned inkscape some new users in the little world of 'low dimensional topology').
Cheers, jfb.
On 01/11/2009 04:42 PM, jf barraud wrote:
Hm... as for "knot" being experimental or not... I dunno; I'd really like to have it added to the next release (it earned inkscape some new users in the little world of 'low dimensional topology').
You know, Knot is a great LPE, and I was working on trying to make a test file a little earlier. Objects that are a single path work whether open or closed, however objects with subpaths do not. When trying objects with subpaths it does not render the effect, or worse, if the two subpaths are a little complex it will lock inkscape up (for example I gave up on a couple after 10 mins of a frozen UI). If that issue could be resolved in a graceful way, I would say I'm all for it.
Cheers, Josh
On 1/11/09, jf barraud <jf.barraud@...400...> wrote:
That is what makes me think lpe should be allowed to register "local" parameters. A new object attribute could be defined (something like "lpe-local-params"), where lpe would register all the data they need. Moreover, I think we'll need this sooner or later to fix the transform issue (lpe cannot be shared atm because the params are transformed along with the object; they'd better stay untransformed, and a local offset transform be stored in each object the effect is applied to...)
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.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Monday, January 12, 2009 01:51 To: jf barraud Cc: Engelen, J.B.C. (Johan); inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
On 1/11/09, jf barraud <jf.barraud@...400...> wrote:
That is what makes me think lpe should be allowed to
register "local"
parameters. A new object attribute could be defined (something like "lpe-local-params"), where lpe would register all the data
they need.
Moreover, I think we'll need this sooner or later to fix
the transform
issue (lpe cannot be shared atm because the params are transformed along with the object; they'd better stay untransformed,
and a local
offset transform be stored in each object the effect is
applied to...)
See https://bugs.launchpad.net/inkscape/+bug/304450/comments/3. What I 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)
Sharing of LPEs is possible, but awkward like it is for gradients. I think we should add a preference to always fork LPEs, like there is for gradients.
If one would want sharing of LPE parameters, a much better option would be to implement something where the value of an LPE parameter can be defined to point to something global. I.e., have the knot spacing defined as "kspacing" in the LPE, which points to a global variable in the SVG that is called "kspacing". Something like this:
<defs> <variables> kspacing = "1.2" <\variables> <lpe123> effect = "knot" spacing = "->kspacing" (instead of spacing="1.2") <lpe123> <lpe456> effect = "knot" spacing = "->kspacing" (instead of spacing="1.2") <lpe456> </defs> <path> d = "..." lpe = #lpe123 <\path> <path> d = "..." lpe = #lpe456 <\path>
Then, it is clear to the user that an effect has a shared parameter (because the widget shows the name "kspacing"), and it is easy to check to see whether all applied knots have that same parameter. And probably there are knots in the document that people do *not* want to have shared.
Also think of possible complexities with LPE stacks and LPE on groups...
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 don't understand what Bulia means. True variable width stroke is already possible. What has not been implemented yet is using a directional pen for stroking and certain pen tip shapes, but JF and I are working on it. It is unimportant for the "transformation propagation" that LPE does now.
Cheers, Johan
Hi!
See https://bugs.launchpad.net/inkscape/+bug/304450/comments/3.
A quick answer about lpe transforms: Of course we somehow need to keep track of all transforms. What I suggest is the following: -- 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.
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).
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.
If one would want sharing of LPE parameters, a much better option would be to implement something where the value of an LPE parameter can be defined to point to something global.
Wow! that would be great. This is not lpe specific: it would be great to be able to link the color to the radius of a circle or whatever... For lpes like sketch for instace, this is not handy at all... while sketch should be considered as a 'stroke style', and hence easily shared.
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.
Cheers. jfb.
-----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)
On 1/12/09, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
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...
Actually, I wasn't saying that we absolutely must to store anything in the path. The length/width array (yes, of course, the lengths must be relative in the range 0..1) can just as well be stored in the LPE, and probably should be stored there for consistency and simplicity. That this data is unique to this specific path is more a question of interpretation - we don't have to "enforce" that in the code any way. Sharing it with other paths may still make sense sometimes, even if most often if will lead to misalignments e.g. between the cusps of the new path and the old path's width maxima.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: maandag 12 januari 2009 18:06 To: Engelen, J.B.C. (Johan) Cc: jf.barraud@...400...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
On 1/12/09, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
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...
Actually, I wasn't saying that we absolutely must to store anything in the path. The length/width array (yes, of course, the lengths must be relative in the range 0..1) can just as well be stored in the LPE, and probably should be stored there for consistency and simplicity. That this data is unique to this specific path is more a question of interpretation - we don't have to "enforce" that in the code any way. Sharing it with other paths may still make sense sometimes, even if most often if will lead to misalignments e.g. between the cusps of the new path and the old path's width maxima.
Yeah that is how I understood your note, which is why I didn't get why you wrote it in the shared/unshared/store_in_path discussion :)
Johan (and everyone),
two questions:
- I think before, dragging a node in Node tool updated the LPE live. Now it only updates when you release. Do you have an idea of what broke this?
- Why do we have both "Freehand shape" and "Pattern along path"? They seem absolutely identical by their controls. Is there any difference in algorithm? If not can we please merge them?
Hey Bulia,
- I think before, dragging a node in Node tool updated the LPE live.
Now it only updates when you release. Do you have an idea of what broke this?
I've noticed the same thing, I don't know what broke this (yet).
- Why do we have both "Freehand shape" and "Pattern along
path"? They seem absolutely identical by their controls. Is there any difference in algorithm? If not can we please merge them?
I saw this one too, it's a question for Max.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: zondag 18 januari 2009 3:01 To: Engelen, J.B.C. (Johan) Cc: jf.barraud@...400...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
Johan (and everyone),
two questions:
- I think before, dragging a node in Node tool updated the LPE live.
Now it only updates when you release. Do you have an idea of what broke this?
- Why do we have both "Freehand shape" and "Pattern along
path"? They seem absolutely identical by their controls. Is there any difference in algorithm? If not can we please merge them?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
-----Original Message----- From: J.B.C.Engelen@...1578... [mailto:J.B.C.Engelen@...1578...] Sent: zondag 18 januari 2009 15:26 To: buliabyak@...400...; Anhalter42@...173... Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
Hey Bulia,
- I think before, dragging a node in Node tool updated the LPE live.
Now it only updates when you release. Do you have an idea of what broke this?
I've noticed the same thing, I don't know what broke this (yet).
Now for me it *does* update the effect live again...
On Tue, Jan 20, 2009 at 3:45 PM, <J.B.C.Engelen@...1578...> wrote:
Now for me it *does* update the effect live again...
Nope, still does not as of 20547. When dragging by mouse, there's no update, only when moving nodes by arrow keys (because there it commits on every keypress).
On Jan 21, 2009, at 8:52 AM, bulia byak wrote:
On Tue, Jan 20, 2009 at 3:45 PM, <J.B.C.Engelen@...1578...> wrote:
Now for me it *does* update the effect live again...
Nope, still does not as of 20547. When dragging by mouse, there's no update, only when moving nodes by arrow keys (because there it commits on every keypress).
I've started to try some runs under valgrind, and right off hand hit a case where preview closing invokes a callback on a previously deleted object.
I'll keep an eye out once I get past, and see if related things might show up.
In the meantime I'd strongly encourage others to run under valgrind now and then.
-----Original Message----- From: Jon A. Cruz [mailto:jon@...18...] Sent: woensdag 21 januari 2009 0:01 To: inkscape-devel List Cc: Engelen, J.B.C. (Johan); Maximilian Albert; bulia byak Subject: Re: [Inkscape-devel] LPE cleanup
On Jan 21, 2009, at 8:52 AM, bulia byak wrote:
On Tue, Jan 20, 2009 at 3:45 PM, <J.B.C.Engelen@...1578...> wrote:
Now for me it *does* update the effect live again...
Nope, still does not as of 20547. When dragging by mouse, there's no update, only when moving nodes by arrow keys (because there
it commits
on every keypress).
I've started to try some runs under valgrind, and right off hand hit a case where preview closing invokes a callback on a previously deleted object.
What do you mean by preview? Do you mean the python effects?
On Jan 21, 2009, at 10:22 AM, J.B.C.Engelen@...1578... wrote:
I've started to try some runs under valgrind, and right off hand hit a case where preview closing invokes a callback on a previously deleted object.
What do you mean by preview? Do you mean the python effects?
In this case it was the file import dialog preview.
I think it's possibly
https://bugs.launchpad.net/inkscape/+bug/306950 and/or https://bugs.launchpad.net/inkscape/+bug/317060 and/or https://bugs.launchpad.net/inkscape/+bug/271621
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: dinsdag 20 januari 2009 22:53 To: Engelen, J.B.C. (Johan) Cc: Anhalter42@...173...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
On Tue, Jan 20, 2009 at 3:45 PM, <J.B.C.Engelen@...1578...> wrote:
Now for me it *does* update the effect live again...
Nope, still does not as of 20547. When dragging by mouse, there's no update, only when moving nodes by arrow keys (because there it commits on every keypress).
For me, it works well with lpe-Bend, but not with lpe-Freehand.
On 1/11/09, jf barraud <jf.barraud@...400...> wrote:
That is what makes me think lpe should be allowed to register "local" parameters. A new object attribute could be defined (something like "lpe-local-params"), where lpe would register all the data they need. Moreover, I think we'll need this sooner or later to fix the transform issue (lpe cannot be shared atm because the params are transformed along with the object; they'd better stay untransformed, and a local offset transform be stored in each object the effect is applied to...)
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.
2009/1/12 bulia byak 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.
In fact there was a bounty from Dave Crossland for that :)
Alexandre
-----Original Message----- From: jf barraud [mailto:jf.barraud@...400...] Sent: Monday, January 12, 2009 00:42 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] LPE cleanup
Hi, Good idea! Notice that test failure is not the only reason to set an lpe as experimental however: the definition of parameters and their internal representation are also relevant. With this respect, "hatches" are clearly experimental atm, as the parameter list is very bad...
Yes, my main reason for wanting test files. (also my main reason for noting all new LPEs as experimental) We must have a well defined and fixed output for the input values. That should never change. (note we did have to change a bit between 0.46 and 0.47 for bend paths, as described in the release notes.)
participants (6)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
jf barraud -
Jon A. Cruz -
Josh Andler