...

2a. Recent reports and testing them under windows show that the transiency code is not perfect. Maybe we'll have to switch "unsinkable dialogs" off on Windows because it behaves erratic there when you try to minimize a document window (maybe this is GTK+ issue). I lean towards accepting the current unsinkable dialogs as temporary solution for the 0.36 release (but not for windows build), but after that I want to explore other options such as GIMP's dockable palettes. Dockability is a good thing in any case, and writing it from scratch is too much work; maybe they will take care of staying on top as well.

That sounds like a good approach. Can you configure it to not use the unsinkable dialogs feature for Windows compiles? Also good idea to investigate dockability; maybe you could add that to the roadmap for 0.37 or 0.38? Perhaps you and Mental can talk about that.

OK

I compiled Inkscape from CVS and played with opening and closing Inkscape and its dialogs after moving dialogs around. A few dialogs seemed to remember their screen location when closed and reopened, but not all.

Sure, only toolbox and ctrl-shift-f, as I explained before

None seemed to remember their location between Inkscape invocations.

That's strange - these two should remember position and size, they do on my system. Is ~/inkscape/preferences.xml created/updated after you exit?

Also I noticed many dialogs first popped up in a corner, whereas it probably would be better for them to pop up either auto-positioned (if possible) or centered in the screen.

OK I'll think about centering those dialogs that don't yet have saved position, but this is minor importance because this position will only be used once - after you drag the dialog to any other place it will remember it and never again pop in the center.

...

2c. I still want someone to test one small change in the transient behavior though. It's simple: Please compile the latest CVS/tarball, open two document windows, maximize both, and switch between them. Does toolbox stay on top? Please report also your window manager. Thanks!

I've tested this on KDE (Mandrake 9.1), the toolbox does not stay on top of the canvas windows when switching via Alt-tab. If I am switching between a single canvas and the toolbar, though, it does.

That's the problem. Here's the dillemma:

- either we have it as it is now, with the problem of dialogs not staying on top when switching maximized windows (at least on KDE),

- or I can fix this problem, but then we'll have another: as reported by Tom von Schwerdtner, "the document window is auto-raising itself when it gets the focus. To me this is is counter-intuitive, as every other gnome application I use follows the window manager settings of not auto-raising windows when they get the focus." I don't use raise-on-click so I did not notice this myself; with raise-on-focus everything seems to be OK.

So we have to choose which of these two problems is more serious. I can think of no way to fix them both. Maybe some magic dockable windows will solve both, but the current transient windows have to choose. I don't want to make this user-configurable because that would be a rather obscure and confusing option. What do you think?

I don't have an opinion on this one and am not familiar with how it's done in other applications, but if I were going to try to guess what the mappings were, I'd probably try ctrl-pgup/dn, then ctrl-up/dn, then (maybe) home/end, and finally if it wasn't any of those I'd look at the keyboard shortcuts list.

So my vote is for Home/End for top/bottom (as it is now) and Ctrl-Home/Ctrl-end for one layer up/down (instead of current pgup/pgdn).

I'll add 'make this decision' to the roadmap. Who do you think would be a good person to make the call? (I also don't have a mouse wheel and also don't have an opinion.)

Alan, can you summarize what is the current consensus (if any)?

--bb