On Sat, 2007-09-01 at 15:38 +0200, momo wrote:

Same problem here, it appeared since the introduction of live preview. Every effect dialog results in a crash.

Can someone on win32 generate a backtrace for this? I definitely isn't the case on Linux. I don't know what would be different there.

Do the effects that don't have dialogs work?

Also, the live preview checkbox stores it's state in your Inkscape preferences. You can toggle it there.

--Ted

Ted Gould wrote:

Can someone on win32 generate a backtrace for this? I definitely isn't the case on Linux. I don't know what would be different there.

Seems like the 'Glib::SpawnError' exception is not being caught, which then terminates the program.

1. From commandline:

E:\Inkscape\inkscape>inkscape ** Message: Found local interpreter, 'E:\Inkscape\inkscape\python\python.exe', Size: 24064 terminate called after throwing an instance of 'Glib::SpawnError'

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it.

2. From within gdb:

(gdb) run Starting program: E:\Inkscape\inkscape/inkscape.exe ** Message: Found local interpreter, 'E:\Inkscape\inkscape\python\python.exe', Size: 24064 warning: HEAP[inkscape.exe]: warning: Invalid Address specified to RtlFreeHeap( 02FA0000, 00F4B808 )

Program received signal SIGTRAP, Trace/breakpoint trap. ---Type <return> to continue, or q <return> to quit--- 0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll (gdb) bt #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll #1 0x7c96c943 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #2 0x0022ea24 in ?? () #3 0x7c96cd80 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #4 0x00f4b800 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::all ocator<wchar_t> >::_Rep::_S_empty_rep_storage () #5 0x02fa0000 in ?? () #6 0x00f4b808 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::all ocator<wchar_t> >::_Rep::_S_empty_rep_storage () #7 0x0022ea98 in ?? () #8 0x7c96df66 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #9 0x02fa0000 in ?? () #10 0x00f4b800 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::all ocator<wchar_t> >::_Rep::_S_empty_rep_storage () #11 0x7c96e11c in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #12 0x02fa0000 in ?? () #13 0x00f4b808 in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::all ocator<wchar_t> >::_Rep::_S_empty_rep_storage () #14 0x40000060 in ?? () #15 0x00000000 in ?? () from #16 0x00000000 in ?? () from #17 0x00000000 in ?? () from #18 0x00000000 in ?? () from etc

Ted Gould wrote:

On Sat, 2007-09-01 at 16:54 +0200, J.B.C.Engelen@...1578... wrote:

...

Ted Gould wrote:

...

Can someone on win32 generate a backtrace for this? I definitely isn't the case on Linux. I don't know what would be different there.

Seems like the 'Glib::SpawnError' exception is not being

caught, which

...

then terminates the program.

Hmm, that's really odd... the only call that I think throws that does have a catch for it...

Is it possible to get a backtrace on a build with symbols compiled in?

Actually, I think this was a backtrace with symbols. (but without code line information) For example, I can break on function names etc. I know it is hard to debug this for non-windows users. But to be honest, I lack the motivation at this moment to solve it myself, sorry :-( (Too busy having fun with LPE's!)

Regards, Johan

Ted,

What is "Pin dialog"? Please provide tooltips for your checkboxes, and please spell them sentence style (only menu commands use Initial Caps).

Thanks for adding Live preview! You were going to also add an indication of it working - is this done?

On 9/2/07, Ted Gould <ted@...11...> wrote:

On Sun, 2007-09-02 at 17:01 -0300, bulia byak wrote:

...

What is "Pin dialog"? Please provide tooltips for your checkboxes, and please spell them sentence style (only menu commands use Initial Caps).

The pin dialog feature basically makes the dialog non-modal. So then you can adjust your selection and run the effect more than once. Also, it can make it easier to run the effect multiple times with different parameters. If you call it a second time the dialog will be brought to the front.

Well, I don't think this looks good in extension UI. "Make dialog non-modal" sounds terribly technical and irrelevant for a user. "Pin dialog" sounds cryptic. Perhaps something like "Allow to change selection" would work but it's still very awkward.

But, do we need this at all? Can we make it non-modal always, and still allow live preview? That would be the perfect solution.

Tool tips are a little trickier. Both of these checkboxes are implemented as preferences (which means they get stored with the effect preferences in the config file) but that means that tooltips are a little bit different. This needs to be fixed for all preferences, but has evaded me the times I've tried. I think I need to wrap everything in an event box and put the tooltip on that, but I haven't tried that yet.

Yes, event boxes are usually the solution for troubles like that.

...

Thanks for adding Live preview! You were going to also add an indication of it working - is this done?

The infrastructure is there, it's a mater of showing it in a good way. I think the best is to add a spinner next to the check box. A little tricker, but text just didn't look good.

Spinner sounds good, though I'm not sure I know how it looks exactly :)

On 9/3/07, Ted Gould <ted@...11...> wrote:

The reason that I used the term "pin" is because I think it's been widely used previously. Many window managers allow you to do things like pin menus or pin windows on all desktops.

I may be wrong, but it seems to be something specific to X Window. I never used that, but I always thought it's something that fixes the _position_ of the dialog. How is this relevant here?

Some even have an icon of a push pin in the title bar. I'm not stuck on this terminology, but I thought it described what was happening well :)

I'm not sure. What is being pinned here and how? From my viewpoint, the only effect of this checkbox is that it allows me to change selection without closing it (and disables preview). The dialog itself does not change in the slightest.

...

But, do we need this at all? Can we make it non-modal always, and still allow live preview? That would be the perfect solution.

I'm not quite sure how that'd work. In essence we'd have to have some sort of document locking as the undo buffers would end up in a weird state. Plus, I'm not sure how it'd work with effects that require the selection of multiple objects.

OK, here's an idea. If your "pin" diables preview anyway, then why not make the Preview checkbox control both modes:

- when it's on, you get live preview and the dialog is modal.

- when it's off, you get no preview but the dialog is not modal and you can change selection.

I think this would be the best functionality compromise without confusing UI.

I think that it's very funny that you're questioning this Mr. "I don't want my export dialog to close when I hit 'export'" :) It's basically the same feature that I'm cloning here.

Of course I'm all for the _feature_ itself. I'm just against the extraneous and confusingly labelled UI :)

On 9/5/07, Ted Gould <ted@...11...> wrote:

Well, we can change the text, what ever makes the most sense. Here's some other ideas:

"Close on Execute" "Lock Document" "Control Document" "Dialog on Top" "Effect Control" "Bulia Only" :)

All wrong, sorry, because they're trying to solve the wrong problem. I see your point about the dialog staying open after OK, but it is very wrong for OK (or Execute) to not close it, no matter what other checkboxes are there! For the always-open dialog, you just need different buttons.

So here's what I propose: replace close/ok/execute buttons with two buttons: Apply and Close (in that order). Remove "pin" checkbox. When live preview is off, make dialog non-modal and allow to change selection at any time; Apply would then just apply to the current selection but not close. When live preview is on, dialog is modal, but you can preview the effect of parameters on the current selection; and when you click Apply it not only applies the effect but _also_ unsets the Live preview, unlocking the dialog to enable new selections.

If someone reqests a button to apply-and-close, a preference option can be added for that.

On 9/5/07, Ted Gould <ted@...11...> wrote:

While I think this could work, it does change the behavior rather significantly from what we have now. I think that with this, live preview should be on by default as people will expect to start working on what they have selected already.

Other dialogs do allow you to work with the selection at once, true. But there's a crucial difference. When you've just opened any dialog (fill&stroke, path effects, whatever), it does not change anything in the document by the very fact of its opening. This is because all the standard dialogs _reflect the current state_ of the selected objects and allow you to change them by changing that state.

Extensions are different; they do not reflect or change the state, they blindly apply a transformation. So if we set preview to on, _just opening the dialog_ will change something (even if this change is "not real" and just a preview), and that is EXTREMELY annoying and has no counterpart in "normal" dialogs. So I remain convinced that the live preview should be off by default.

Consider also that, if you accept my plan, the default opened state of an extension dialog will allow you to change selection. And this is an aspect which will make the extension dialogs a lot more like all others, so it is an important improvement.

Do the "perception speedups" that I added make enabling preview by default seem reasonable to you?

I guess the answer is no, although I'm not entirely sure what you mean by "perception speedups" :)

On 9/6/07, Ted Gould wrote:

Now I think one thing that bothers me is the idea that there could be hundreds of new palettes created by doing this. Every effect would have it's own. Does it make sense to have an "Effects Palette" instead?

Sounds good, but whaqt do we do with our multitab extension dialogs like Function plotter?

Alexandre

On 9/6/07, Ted Gould <ted@...11...> wrote:

I feel like the previous (0.45) interaction was a pretty standard one. Basically someone clicks on a menu, gets some options, changes those, and then changes the document based on those settings. It then disappears.

We also have dialogs that are more related to adjusting properties of objects. So, for instance, you can change the fill and stroke styles of an object by using the fill and stroke dialog.

So, in essence we'd be mixing these modes to create a dialog that would appear upon selecting a menu item -- but would remain as you continue to work with the document. It is less of an "OK" check box coming up and more of a palette.

Yes, it's a mix, but I don't see any problem with that. It's actually more similar to Export, which is also always-on but performing one-time actions (though it does not visibly change the document).

Now I think one thing that bothers me is the idea that there could be hundreds of new palettes created by doing this. Every effect would have it's own.

How it's different from what we have now? Well, actually many effects have no params and dialogs at all now, and they will not receive them because of the changes we're discussing.

Does it make sense to have an "Effects Palette" instead?

I don't think it's a good idea. One monstrous dialog with inconvenient tab selection, instead of a menu? Why? What problem does it solve?

...

...

Do the "perception speedups" that I added make enabling preview by default seem reasonable to you?

I guess the answer is no, although I'm not entirely sure what you mean by "perception speedups" :)

Sorry, should have explained :) No there is more events taken into account in large documents so there should be less locking of the UI. Also, rapid changing of preferences doesn't cause the live preview to be re-rendered immediately -- there is a short timeout. This fixes the problem of holding down a spin button (especially on large docs).

That is very good in itself - but still, I remain against preview being on by default, sorry :)

On 9/7/07, Ted Gould <ted@...11...> wrote:

...

...

Now I think one thing that bothers me is the idea that there could be hundreds of new palettes created by doing this. Every effect would have it's own.

How it's different from what we have now? Well, actually many effects have no params and dialogs at all now, and they will not receive them because of the changes we're discussing.

I guess the key difference for me is that you couldn't have all of them open at the same time before. Now, in theory, you could open them. I need a few 24" monitors :)

Well, a user can do a million other things to make his life harder :) Why do we need to aggressively watch and prevent all of them? We only need to provide guardrails where it's easy to do something foolish _accidentally_, but laboriously opening all extensions dialogs does not count as accidental in my book :)

By the way, what do you think about making all the extension dialogs dockable, docked by default? There are many advantages:

- more consistent UI;

- this will further justify their always-on status, because closing a dialog by OK when that dialog is docked would look rather weird anyway;

- we'll then be able to get rid of the Close button altogether, because no other docked dialogs have it.

There's only one problem with this: I'm not sure how it will be possible to make the rest of the window disabled (to prevent selections) when you click Live preview, when the dialog is docked and not a separate window. But this leads me to another idea. What if we get rid of that modal-window, no-selection-possible thing at all? Right now, as I understand it, it simply undoes the last change when it senses a change in params and runs the effect again. What if, in the live preview mode, we lock the repr tree from any change but allow selection tools, and also make it undo the effect change whenever it senses any selection_changed event? Do you think it's viable in principle?

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

Having a systemic way to prohibit document changes would be good for many things beyond just live effects.

So, Mental, as the main repr tree expert, maybe you can quickly implement it?

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

When client code tries to modify a locked document, should we fail silently or report an error?

Of course it must not crash or write anything to the console. But it must perhaps set some flag which will let me find out if changes are currently allowed or not. Old code that does not check this flag, however, must simply notice nothing and fail silently and painlessly.

On Tue, 2007-09-11 at 10:44 -0700, MenTaLguY wrote:

On Tue, 11 Sep 2007 00:38:16 -0300, "bulia byak" <buliabyak@...400...> wrote:

...

But it must perhaps set some flag which will let me find out if changes are currently allowed or not.

Hm, yes -- I think changability should be advertised on both SPDocument and XML::Document; it would probably be good to have an SPDocument signal which notified when the document was locked or unlocked, too.

Will this effect the canvas redrawing? The live preview kinda depends on it redrawing.

...

Old code that does not check this flag, however, must simply notice nothing and fail silently and painlessly.

It may not always be silent and painless. Code which relies soley on repr notifications to update its state should be okay, but code which sets the repr and then assumes that whatever it set was taken may get out of sync and crash. We've had problems in the past with code that got confused by additional changes made from repr handlers, so likely we will have similar issues again.

I'm still torn both ways, but the one advantage to obvious crashes is that they get fixed quickly (versus more subtle bugs).

I think this is a good use of printfs. Most of the people who need to see them will. I think it's important enough to justify the console output.

--Ted

On Wed, 2007-09-12 at 00:01 -0300, bulia byak wrote:

I think it is assumed that, when params change, the effect dialog will temporarily unlock the tree, undo if necessary, replace document with the processed version (so everything redraws), and lock again.

That wouldn't stop commands from being processed anymore, though.

It sounds like what we really want is a facility to selectively deny changes from specific sources.

-mental

On Wed, 2007-09-12 at 20:36 -0700, Ted Gould wrote:

Are you thinking something like a reader/writer lock? It seems like that's more the mechanism that we're looking for.

Well, only sort of. We'd first need to be able to distinguish between different sources of modifications for them to be able to exclude one another.

Eventually it could be possible to open multiple "database handles" into a single XML::Document (with transaction isolation and/or locks), but I would need to get through some of the heavy refactoring I have planned before that would be possible, so it is not a short-term solution.

-mental

On 9/17/07, Ted Gould <ted@...11...> wrote:

We change the dialog to have a combo box labeled "Dialog Mode:" with the following options:

"On Top" "On Top; Live Preview" "Floating"

"On top" and "floating" do not sound like meaningful opposites. More importantly, this must never be something that the user chooses or even has to think of. We must take care of that and not even let the user suspect that there was any problem with that. Providing this choice would be like a builder asking, "Do you want your house with roof on top or on bottom?"

So, if we don't have change lock in 0.46 and the extension dialogs are not yet dockable, we're back to my original suggestion:

Replace close/ok/execute buttons with two buttons: Apply and Close (in that order). Remove "pin" checkbox. When live preview is off, make dialog non-modal and allow to change selection at any time; Apply would then just apply to the current selection but not close. When live preview is on, dialog is modal, but you can preview the effect of parameters on the current selection; and when you click Apply it not only applies the effect but _also_ unsets the Live preview, unlocking the dialog to enable new selections.

At least this must be the first step.

On 9/18/07, Ted Gould <ted@...11...> wrote:

...

"On top" and "floating" do not sound like meaningful opposites. More importantly, this must never be something that the user chooses or even has to think of. We must take care of that and not even let the user suspect that there was any problem with that. Providing this choice would be like a builder asking, "Do you want your house with roof on top or on bottom?"

I don't think that's the case. If that's the case having an option like "docked" or "undocked" is exactly the same.

Yes, and guess what, we don't have such an option either :) Instead we allow the user to simply drag the dialog to where he wants it. We don't force him to think about what "docked" or "undocked" means (at least not without going into prefs, which is another story), and we don't couple the dialog status with some absolutely orthogonal functionality like preview. Docked or undocked, our dialogs work exactly the same.

They're all technical terms related to the condition and state of the user interface.

Yes, and there's no need to burden the user with these technical terms. If we must, due to our limitations, do some unnatural and technical thing - such as make the dialog modal - this must only come as a consequence of some _meaningful_ user choice, such as enabling or disabling preview. (Of course it must warn abundantly that enabling preview locks your editing window, e.g. by statusbar message, tooltips, etc.)

This does not leave in place the way that the dialogs currently work.

Yes, it basically turns them into always-on dialogs which can be used repeatedly without closing. I see no problem with that.

I think by default they should work in the way that they are used.

They already are changed quite a lot, and not all changes are good. I really don't like the "pin dialog" thing, as I explained. And I'm afraid the "floating/on top" choice you propose instead is not really any better.

By providing a combo box we can achieve having the dialog work in the current way. You can then turn on live preview or just having the dialog stick around. I think it's important to maintain that functionality for existing users.

If I want it to "stick around", I simply don't close it. If I don't want it to stick around, I close it. As simple as that. No need to add confusing options to the dialog itself.

On Mon, 2007-09-17 at 22:17 +0400, Alexandre Prokoudine wrote:

On 9/17/07, Ted Gould wrote:

...

We change the dialog to have a combo box labeled "Dialog Mode:" with the following options:

"On Top" "On Top; Live Preview" "Floating"

By the way, why does "Floating" disable "Live Preview"?

Yes. It would unlock the document so that you could change your selection.

--Ted