Re: GTK_WINDOW_DIALOG



On 20 Feb 2001, Havoc Pennington wrote:

> One issue is how this interacts with _NET_WM_WINDOW_TYPE (see
> http://www.freedesktop.org/standards/wm-spec/x183.html), though I
> don't think it makes any difference - we can set
> _NET_WM_WINDOW_TYPE_DIALOG anytime the transient_for hint is set.
>
> I guess it's possible to have a dialog without a parent onscreen
> though, so this whole transient_for = dialog deal may be broken in
> that respect.

What about non-modal dialogs? Sawfish have a setting where transients are
kept in front of it's main window. Thats okay for modal dialogs but might
be bad for non-modal dialogs (if there are such things).

One thing that keeps biting me is the window-history feature of sawfish
that very often misstakes dialogs as the main window and resizes the
dialog to the same size as the main window. if the dialog are marked as
transient it always works but many programs forgets about the transient
flag and some programs really uses dialogs that should not be transient.

The problem is that all the windows, transient or not, usually have the
same WM_CLASS. Should they really have that? This is yet another thing
that should be documented somewhere in some guidelines. In my programs I
usually makes sure that the different kinds of windows have different
window classes (right or wrong, it seems to work well)

-- 
/Dennis





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]