
On Sun, 23 Nov 2003, bulia byak wrote:
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
Yes you're right; I'm reading my emails out of order...
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?
I tried it again, and yes you're right it does save the position and size of the dialog correctly.
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.
Okay. Yes you're right that users will encounter this once only, but it will be a 'first impressions' kind of thing as well.
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?
You know, I probably wouldn't have noticed it if you hadn't have mentioned it. Go with the first approach, but put some comments explaining these issues. If someone doesn't like the behavior, they can review your notes and submit a patch if they can find a better solution.
Thanks, Bryce