Re: Decorations (again)

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

On Tue, 9 Nov 1999, Michael ROGERS wrote:

> I agree that logical hints would be preferable from the WM's point of view, 
> but the application programmer may still want to "disallow" certain functions 
> (such as resize or close). We seem to have two choices:

[...]

> 2. Use categories to define a window's visual appearance, but specific hints
> to define its behaviour. For example, we might have the following visual 
> categories:
> 
> Main window (implies full range of WM decoration)
> Dialog  (implies small decorations, temporary)
> Toolbar (implies small decorations, permanent)
> Undecorated (covers stuff like desktop shortcuts as well as pinned menus -
> implies that no WM buttons or borders will be available)
> 
> and the following functional hints:
> 
> Keep above normal windows
> Keep below normal windows
> Present on all desktops
> Modal (target of _WM_TRANSIENT_FOR cannot be focused)
> Group modal (no other members of group can be focused)

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

> Examples:
> 
> An error message box might request dialog decoration, keep above normal 
> windows, and modal.

As above, I think the "ontop" hint should describe its position relative
to other dialogs, not to normal windows, IYSWIM.

> The GIMP toolbar might request toolbar decoration.
> File manager icons might request undecorated state, and keep below normal 
> windows.

No, I think they should declare themselves as "desktop" windows. 

> A file manager window might request main window decoration.
> The Gnome panel might request undecorated state, keep above normal windows (or
> keep below normal windows, according to the user's preference), and present on 
> all desktops (according to the user's preference).

No, I think the panel should call itself a dock window.  This will allow
it to be stacked differently from any other window with the ontop hint
set.

Eg.  A CD player will call itself a normal window, but offer the user the
option of making it ontop.  In this case, I still want it stacked in a
different layer from my panel windows.

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

> Anyway sorry if I am beating the point to death.  :)  I just think we can make
> the spec flexible enough for 99% of applications without very much complexity.

I think you are right.  I would be reluctant to put in such functionality
as filemanager windows, or horizontal shading.  I feel that these are best
handled as application specific, or wm specific extensions.

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.

cheers,

Paul