Re: Decorations (again)

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

>One of the problems I see with the MOTIF hints is there visual nature. They
>give applications control to decide what kind of buttons or functions shall be
>visible on the window decoration. This is a concept directly taken from
>Windows-2.0, I assume, and doesn't fit well into the X world where window
>managers are the ones responsible for window decoration and window management.
>
>So the basic idea is to introduce a *logical* decoration hint. Last time we
>discussed that I wasn't very creative finding logical window groups. We
>basically had the three visual groups:
>
>       - normal windows ( the WM already knows if something is a dialog with
>                                     the transient_for hint)
>
>      - toolwindows (usually smaller decorations )
>
>       - windows that do not want to be decorated (but managed to gain focus
>                handling. Panels and such are in this cathegory).
>
>       - windows that do not want any decoration but want to be resizeable by
>             the wm with a tiny frame (floating toolbars, etc.).
>
>
>Not very logical, I admit, but practical. Will cover a lot of cases, but
>there's more to it:
>
>What about the additional groups:
>
>      - message box
>      - critical message box
>      - error message box 
>        ( these hints may also influence the WMs activation behaviour)        

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:

1. Create a huge number of logical categories. This thread seems to be heading
that way already. :) The advantage is that no matter how you want your window 
to behave, you can probably find a category that describes it. The problem (as 
I see it) is that each new category is proposed because we want windows of 
that category to behave in a specific way (horizontal shading, docking, 
auto-raise, beep and dance around the screen, etc). So really these are visual 
categories as much as logical categories.

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)

Examples:

An error message box might request dialog decoration, keep above normal 
windows, and modal.
The GIMP toolbar might request toolbar decoration.
File manager icons might request undecorated state, and keep below normal 
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).

This would allow things like gtk_set_policy() that rely on MWM hints to keep
working, while removing the visual part of the MWM hints which I agree is
inflexible.

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.
The other 1% could always be specifically identified and handled by the WM 
(just like twm allows named windows to be decorated differently).


Michael Rogers