Guy Harris wrote:
On Sun, May 23, 2004 at 03:24:34AM +0200, Ulf Lamping wrote:
-the main window showing the one and only document
-utility/derived windows which may stay on the screen for a while
-dialog windows which will usually immediately be closed again, after
some user input done
The main question to me is: How should these windows *behave* (e.g.
regarding to the main window)? And maybe even more important: Are there
differences between the dialogs and the utility windows?
Some points to think about:
-transient to main window or not? (e.g. on win32, a transient window
will not be shown in the tasklist for example)
"Tasklist" as in the task bar?
Both the task bar (usually at the bottom of the screen) and the tasklist
(when using alt-tab to switch between
windows)
-save size and position of the window until next appearance?
So saving the size and position should be done for all window classes? I
would agree with this.
I need a better word for window class. My current implementation (not
checked in) is keeping the size and position of the window by creating a
hashtable, with the initial window title as the hashkey.
So every window with a (at creation time) unique title will build it's
own window class. Changes of the title after window_new() doesn't change
the window class.
-remains on top of the main window?
-can remain unminimized even if the main window is minimized?
For the derived view windows, I'd say "no" and "yes", respectively, for
the latter two questions. If "transient to main window" implies
"remains on top of the main window" or "automatically minimized if the
main window is minimized", I'd say that derived-view windows should
*not* be transient to the main window.
If you can minimize the main window without minimizing derived view
windows, the derived view windows should have separate taskbar items.
Another example of a "derived view window" is the "View source" window
in a Web browser; I'll have to see how various browsers handle that
window on Windows and in KDE.
After looking a bit around, I think I get what you mean.
A derived window behave much like another application window, except
that it will be closed when Ethereal is closed
(and maybe centered at Ethereal's application window when initially shown).
So the usage of window_new() was ok before, I just didn't understand it
correct.
I don't like a lot of windows floating around on my desktop that belongs
to a single application, but that's my own personal taste, of course.
But as it's the correct way like you describe it,
I will change the derived windows back to window_new(), so they will
behave as they should.
For the derived windows, we later might want to have something like the
tabbed browsing in Mozilla, so these windows will be "attached" to the
main window.
This should be optional, and will require a lot more effort, as all the
derived windows have to be splitted into a content part and the
windowing things
(..., and some of them have a mixed row of buttons, some buttons window
related, some buttons content related (e.g. RTP streams statistics), and
...).
And (when thinking a bit further) the content panes of the main window
are not really different to the other derived windows. So there seems to be
a lot more things to think about. But nothing which could/will be done
in the next two days :-)
Regards, ULFL