Re: How to position a dialog box atop an application's main window?
- From: Guy Harris <gharris flashcom net>
- To: Havoc Pennington <hp redhat com>
- Cc: Guy Harris <gharris flashcom net>, gtk-list gnome org
- Subject: Re: How to position a dialog box atop an application's main window?
- Date: Sun, 9 Jul 2000 23:33:52 -0700
On Tue, Jul 04, 2000 at 12:45:45AM -0400, Havoc Pennington wrote:
>
> Guy Harris <gharris@flashcom.net> writes:
> > I remember some discussion within, I think, the past few months about
> > how to make dialog boxes for an application pop up atop the main window
> > for the application, rather than being placed wherever the window
> > manager feels like it (which appears to mean "placed somewhere random,
> > often not near the window, so that you don't necessarily see it pop up).
> >
>
> If you set the transient for hint, either the window manager will do
> something good, or the window manager is sucking.
Maybe they're just old versions, but
the KWM that comes with KDE 1.1.2;
olvwm (yeah, I know, it's a tired old window manager, but the
guy on whose machine I tried it is an old Sun guy);
the window management code in the Exceed 6.0 (or maybe it was
6.1) server for NT;
AfterStep;
all appeared not to make a particularly vigorous effort to place the
dialog boxes atop the main window.
Are there any that *do* make an effort to position transient-for windows
atop the window for which they're transient?
Now, given that both olvwm and AfterStep were configured to use focus
follows mouse, placing dialogs atop the main window might not be the
best choice; placing them so that they're under the mouse, so that they
get the input focus and you can immediately start typing in them, might
be a better choice.
The window managers in question didn't do that, either, however.
> > (I have the impression that window managers don't necessarily to
> > position transient-for windows atop the window for which they're
> > transient, and can't necessarily even be configured by the user to do
> > this - I didn't find any obvious code in KWM to do this, for example;
>
> Right, but users do choose a window manager they like, so if their WM
> lacks this feature it really isn't your place to add it. Many people
> prefer GTK_WIN_POS_MOUSE type of behavior for example.
...especially with focus-follows-cursor.
However, the version of "gnome-dialog.c" in gnome-libs-1.0.56, at least,
checks, in "gnome_dialog_set_parent()", if the user specified that their
preference is to center dialog boxes atop the main window, and, if they
did, does so:
gtk_window_set_transient_for (GTK_WINDOW(dialog), parent);
if ( gnome_preferences_get_dialog_centered() ) {
/* User wants us to center over parent */
gint x, y, w, h, dialog_x, dialog_y;
if ( ! GTK_WIDGET_VISIBLE(parent)) return; /* Can't get its
size/pos */
/* Throw out other positioning */
gtk_window_set_position(GTK_WINDOW(dialog),GTK_WIN_POS_NONE);
gdk_window_get_origin (GTK_WIDGET(parent)->window, &x, &y);
gdk_window_get_size (GTK_WIDGET(parent)->window, &w, &h);
/* The problem here is we don't know how big the dialog is.
So "centered" isn't really true. We'll go with
"kind of more or less on top" */
dialog_x = x + w/4;
dialog_y = y + h/4;
gtk_widget_set_uposition(GTK_WIDGET(dialog), dialog_x, dialog_y);
}
"gnome_dialog_init()" initially sets the position to the result of
"gnome_preferences_get_dialog_position()", which appears to offer a
choice of "None" (stick it wherever the WM chooses, presumably, i.e.
GTK_WIN_POS_NONE), "Center" (put it in the center of the screen, i.e.
GTK_WIN_POS_CENTER), and "Mouse" (put it under the mouse, i.e.
GTK_WIN_POS_MOUSE).
In the best of all possible worlds, perhaps many window managers would
offer the option of specifying what should be done about transient-for
windows, including "use the same positioning rules as are used for other
windows", "put them under the mouse", and "put them in the center of the
window for which they're transient"; however, given that GTK+ offers two
positioning options other than "leave it up to the window manager", and
GNOME offers "center it relative to the parent window" over and above
the GTK+ choices, it sounds as if we may not live in that best of all
possible worlds, and that GTK+ and GNOME *do* add at least some
behaviors that window managers might not offer.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]