On 9/4/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:

...

The path-along-path lpe crashes when applied to a closed path.

No longer crashes, but not fixed yet. Now, I think effects can no longer crash inkscape; effects that would crash otherwise now return the input path without modifying anything.

Thanks!

...

Also, is it possible to add a width scaler for this effect? So it would scale the path being bent perpendicularly to the skeleton path in every point. That would make using it much easier.

Done.

Thanks, but why that new checkbutton "scale y"? With it off, the scale spinbutton has no effect at all. I think you need to just remove that checkbox and let the spinbutton always have effect on Y. If you later add a way to scale in X (which would obviously only work for unstretched modes), just provide a separate spinbutton for it.

Also, right now your Y scaling seems to be in the units of the path length. This is a useful choice, but in other situations it will be useful to scale it in multiples of the original path's height, so that one could apply the same _absolute_ width to a selection of paths even if they are all different lengths. Can you please add this possibility and a corresponding switch to the effect's UI?

Finally, for the width values, I think two fractional digits is not sufficient. Can you make it three?

Done! Including menu item, but I could not quickly think of a (free) keyboard shortcut.

Since you used Ctrl+Shift+7 for the dialog (which looked weird to me at first, but now I like it), what about Ctrl+7 for pasting LPE? It has the advantage of 7 looking almost like a rotated V :)

I'll see what can be done to the runaway spinbuttons problem.

One note about terminology: I agree that "effect" is too overloaded, but I don't think that adding "live" to it helps much :) It sounds a little too marketoid to me. I'm not against calling the whole system "live path effects", but where we need an abbreviated name, I think "path effects" would be more informative than "live effects". What do you think?

Bulia wrote:

Thanks, but why that new checkbutton "scale y"? With it off, the scale spinbutton has no effect at all. I think you need to just remove that checkbox and let the spinbutton always have effect on Y. If you later add a way to scale in X (which would obviously only work for unstretched modes), just provide a separate spinbutton for it.

Also, right now your Y scaling seems to be in the units of the path length. This is a useful choice, but in other situations it will be useful to scale it in multiples of the original path's height, so that one could apply the same _absolute_ width to a selection of paths even if they are all different lengths. Can you please add this possibility and a corresponding switch to the effect's UI?

Actually, at the moment, X scaling is always on for the stretch modi: the original X is scaled to fit. Josh mentioned that 'Y' might sound strange to people, and that 'proportional' scaling may be better. I agree with that, so I made the Y-scaling into a scaling ratio thingie. But with that, when bending the path, the X-length would change and so would the Y-width for a fixed ratio. Maybe I should change the checkbox into: absolute Y scaling or relative to X. That would make all options possible, right? (note that all this equally applies to the Curve Stiching)

Finally, for the width values, I think two fractional digits is not sufficient. Can you make it three?

Agreed, easy enough.

Since you used Ctrl+Shift+7 for the dialog (which looked weird to me at first, but now I like it), what about Ctrl+7 for pasting LPE? It has the advantage of 7 looking almost like a rotated V :)

The ampersand on top of the 7 looks like a curved path :) That's how inspired I was when choosing the 7 ! :P

I'll see what can be done to the runaway spinbuttons problem.

Thanks a lot !!!

One note about terminology: I agree that "effect" is too overloaded, but I don't think that adding "live" to it helps much :) It sounds a little too marketoid to me. I'm not against calling the whole system "live path effects", but where we need an abbreviated name, I think "path effects" would be more informative than "live effects". What do you think?

Ah that is a good one. It sets it more apart from the Live Effects *Preview* thing (often with preview omitted), which is good. Please note that I am not much of a UI expert, and since English is not my native language, not very creative with word usage. I would very much like people to rephrase LPE wordings, and especially the widget layout of the LPE dialog. (Also, I do not like the "apply" and "remove" things in the LPE dialog at all. They really should be put somewhere else, separated from the parameters.)

Johan

On 9/4/07, bulia byak <buliabyak@...400...> wrote:

I'll see what can be done to the runaway spinbuttons problem.

Well, I sort of patched it. Not a real fix because it's obviously a GTK bug. I just desensitived the spinbutton while it's updating the repr. Now it's stable, but also it does not autoscroll anymore if you press and hold the arrow button.

On 9/5/07, MenTaLguY <mental@...3...> wrote:

On Wed, 5 Sep 2007 03:12:19 -0300, "bulia byak" <buliabyak@...400...> wrote:

...

Well, I sort of patched it. Not a real fix because it's obviously a GTK bug.

Are you certain? It sounds like a feedback loop created by the event handler.

You're right that there was a feedback loop. I didn't notice it yesterday but now I fixed it. But this didn't fix the problem :) This IS a gtk bug.

Here's what happens. If you click and hold the arrow button to scroll the spinbutton, it enters autoscroll mode, in which it sends multiple value-changed events. An event causes writing to repr and document update, which is slow. While an event is processed, new value-changing events as well as setting the spinbutton value from within the program are both blocked, so there's no feedback loop in our code. Those value-changing events that arrive during our value-changed callback are indeed dropped, I checked that. But there's always at least one more event that comes AFTER the value-changed callback is finished and the widget is unblocked, and the callback runs again. And the biggest problem is that (probably because of that blocking?) the spinbutton loses the mouse-release event, and thus keeps autoscrolling forever (although it can be stopped by some other input events - clicking buttons etc.)

Another, worse trouble with undo/redo:

- copy a path

- select a path

- via the dialog, apply path-on-path

- paste the copied pattern path

- undo - pattern disappears (correct)

- undo - effect is not removed! (incorrect)

- undo - now effect is removed

- redo - crash!

(inkscape:25029): GLib-GObject-WARNING **: invalid cast from `GtkLabel' to `SPObject'

** ERROR **: file sp-object.cpp: line 1049 (void sp_object_read_attr(SPObject*, const gchar*)): assertion failed: (SP_IS_OBJECT(object)) aborting...

Johan, please read the email I sent recently to you and Max with the notes on undo system and review all your code for undo-correctness. Basically, when a repr changes, you must sense that and rebuild everything else from the repr - then undo/redo will work fine. Ask me if you have any questions.