Re: forcing a window to the front?
- From: Havoc Pennington <hp redhat com>
- To: Paul Davis <pbd Op Net>
- Cc: GTK List <gtk-list gnome org>
- Subject: Re: forcing a window to the front?
- Date: 18 Mar 2001 19:49:23 -0500
Paul Davis <pbd Op Net> writes:
> my own preference (1) design things so that modal windows are not
> necessary and/or (2) use GTK_WINDOW_POPUP as the window type which
> will keep it on top (if the WM plays along), i believe.
>
GTK_WINDOW_POPUP means that the "override redirect" flag is set on the
window, which means the window manager is supposed to totally ignore
the window. That is, no ability to move/resize/iconify, no window
borders, not in the task list, nothing. Totally nonexistent from the
WM standpoint. The WM will not raise/lower/reorder the window. It will
just ignore it entirely. So this is normally used for tooltips and
GtkMenu. It is not correct for dialogs or application windows, since
even if you don't want titlebars/borders, normally yuu want WM
features such as keybindings, alt-click to move, taskbars, focus
management etc.
If you want to work with the window manager, set the transient_for
hint with gtk_window_set_transient_for(). This hint causes Sawfish
(for example) to keep the transient on top of the window it's
transient for. Though window managers are free to treat this hint as
they like, the meaning of the hint is "the transient window is a
dialog belonging to the given parent," and a reasonable window manager
will probably keep it on top of the parent.
With the new window manager spec on www.freedesktop.org, GTK can also
tell window managers whether a transient window is modal or not modal,
so the WM can be expected to provide even more intelligent behavior in
the future.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]