Re: Decorations (again)

[Paul Warren <pdw ferret lmh ox ac uk>]

On Tue, 9 Nov 1999, Michael ROGERS wrote:

> 
> >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. 

I don't think there is a conflict.  The categories
(desktop,normal,dialog,etc.) should be used to derive the stacking order,
but they are not layers in themselves.  There is no reason why dialogs and
normal windows (or any other window) cannot be mixed together in stacking
order.  

> 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. 

I was trying to get away from dictating layers policy to the WM, which
many people objected to.  Instead, windows indicate their type, and the
WM works out a layers/stacking scheme as it sees fit.

> Tying 
> stacking order to visual category seems to be an unnecessary restriction.

Indeed it would.

> >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. 

I was slightly dubious about that myself, but I don't think it is so bad.
The ontop/below hint is, whatever we doing, going to be fairly meaningless
for eg. desktop windows, and panel windows.

> Maybe
> a separate functional hint ("urgent") is needed? 

Well there is already the ICCCM ugency hint, but that is not quite what we
are trying to acheive.  We are trying to mark the type of a dialog box.
Such a hint would probably indicate one of info/error/critical or similar,
which I feel maps reasonably well onto the below/normal/ontop hint.

Perhaps distinguishing between dialog types is getting too involved for
this spec.  Dialogs can set the ICCCM urgent hint if they feel they are
critical, otherwise they are just normal dialogs.


> This would allow windows of
> any visual category, not just dialogs, to inform the user of an important
> event by setting this hint.

That is what the ICCCM hint is for.

> >> 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().  :\  

I suggest that the way to stop an app being resized by the user is using
the WM_SIZE_HINT, setting both min and max sizes to the desired size. We
could state that a wm is free to interpret minsize == maxsize as meaning
no-resize decorations.  An explicit no-resize functional hint would seem
to duplicate this information, although conceivably might make programming
at both ends easier.  What do you reckon?

> 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.

Yeah, I think most WMs in their right minds will continue to support MWM
for some time to come.  I would hope, however, that most WMs - even not DE
orientated ones, will adapt to use this specification reasonably quickly,
and that toolkits and apps will use this spec in favour of MWM.  We should
not have MWM support as a *requirement* of this spec.

Paul