Re: Decorations (again)

[Michael ROGERS <M Rogers cs ucl ac uk>]

>This is very similar to what I was heading for.  But add to the top list
>"Desktop" and "Dock/Panel", so that we make the first hint a description
>of the window's role.  We then have the functional hints, as you suggest,
>except that the stacking should be determined primarily by the first hint.  
>A window can then use the second hint to indicate that it likes to be on
>top of or below other such windows.

The only problem is that this conflicts with (the option of) keeping transients
and their owners together in the stacking order. You would end up with one
layer of docks, then a layer of dialogs, then a layer of top-level windows,
etc. A combination of layers and categories would allow more flexibility - eg
a layer of docks (undecorated + on top), a layer of urgent dialogs (dialog + 
on top), a layer of normal windows (main window or dialog or toolbar +
normal), a layer of desktop features (undecorated + below), etc. Tying 
stacking order to visual category seems to be an unnecessary restriction.

>The only bit I'm not sure about is whether to distinguish between
>different types of dialog box - warning, info, error etc.  I think that
>dialogs could use the [ontop/normal/below] hint for this.  A critical
>dialog would declare itself "ontop" and a purely info one would declare
>itself "below".  It is up to the WM to then handle these as it pleases.  
>For example, one interpretation might be: A "below" dialog gets stacked
>just above its parent. A "normal" dialog gets stacked above all windows on
>the current desktop An "ontop" dialog gets stacked above all windows and
>warps to that desktop.  Or whatever the wm sees fit.

I think this model ("layer dictates stacking order") makes more sense than 
the "appearance dictates stacking" order model. However, I don't think the
layers should have a different meaning for each category of windows. Maybe
a separate functional hint ("urgent") is needed? This would allow windows of
any visual category, not just dialogs, to inform the user of an important
event by setting this hint.

>> This would allow things like gtk_set_policy() that rely on MWM hints to keep
>> working, 
>
>Could you expand on that a bit, please - I don't know enough about GTK or
>its dependance on MWM hints to understand what you are saying.

Sorry, I had the name wrong - it's gtk_window_set_policy(GtkWindow* window,
gint allow_shrink, gint allow_grow, gint auto_shrink). I think if the first
two are set to FALSE, FALSE the MWM decoration and function hints for resize 
are set to false. I was just reminded of this because someone on the 
gnome-devel-list asked how he could stop his application's window from being
resized by the user. My post to this list originally included a functional 
hint for "No resize", but when I cut that out I forgot to remove the reference 
to gtk_set_policy().  :\  It does reveal a loose end though - I suppose GTK+ 
will keep using MWM hints for ex-Gnome compatibility, so we are probably tied 
to supporting them in addition to any new hints, even in Gnome-specific window
managers.

On a related note, gtk_window_new(GtkWindowType type) can take the arguments
GTK_WINDOW_TOPLEVEL, GTK_WINDOW_DIALOG or GTK_WINDOW_POPUP. We should probably
consider these (and the Qt equivalents) when naming window classes. GTK+ and 
Qt can be changed behind the scenes to use new hints, but the API will
presumably remain compatible, so these names still need to be meaningful.

Can any toolkit developers clarify the position of GTK and Qt WRT this spec?

>What do you feel about what I have outlined above?  We need to give the WM
>enough info to handle windows according to their type (eg. Desktop and
>panel windows may have exactly the same position, regardless of the
>viewport), but to know where to draw the line when the list of window
>types gets excessive.

I think we should separate visual hints (like the main window/dialog/toolbar
categories) from functional hints (like layers). That way we can keep the
number of categories small while allowing a wide range of behaviours to be
specified.


Michael