Re: Decorations (again)

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

>The ability to set normal windows as "ontop" (and possibly "below") I
>think is essential.  Perhaps this could go into the second group. 
>
>> Does anyone think we need more flexibility than the following hints will 
>> provide (except for unique cases which might be better handled on an
>> individual basis)?
>
>I think that pinnable menus are as widespread as toolbars, and as I
>indicated, I think there is a case for distinguishing them to allow for
>functional and visual differences from other windows.

Fair enough - although arguably, menus and toolbars require the same 
decorations (small, probably just the ability to move and close them).

>What about windows that want no decoration at all, but still wish to be
>managed?  Perhaps that should be a hint?  Or do we invent some more
>categories?

If we have an Undecorated category, and a "Keep above" and "Keep below" hint,
docks and desktop icons can use a combination of these, so we don't need Dock
or Desktop categories. Sounds familiar...  ;)

>And one final point: the current draft has 
>
>#define _NET_WM_HINTS_STANDALONE_MENUBAR  (1<<4)         /* this window is
>a standalone menubar */
>
>Where does that fit into all this?  (I'd say it doesn't :-)

I'm sure menubars can be squeezed into one of the existing categories.  :)

>Apart from that it looks pretty good.
>
>> Categories (set zero or one):
>> 
>> Desktop feature
>> Dock
>> Main window (default)
>> Dialog
>> Toolbar
>> 
>> Hints (set zero or more):
>> 
>> Modal
>> Group modal
>> Urgent
>
>The ICCCM hint, or another one?

I meant the ICCCM one, so I suppose it doesn't belong in this list.

>> Omnipresent
>
>Currently this is handled by setting the desktop to 0xFFFFFFF.

OK. This gives us:

Categories:

Undecorated
Toolbar      } Merge these into a
Menu         } single category?
Dialog
Main window

New hints:

Stay on top
Stay below
Modal
Group modal

Any additions? Subtractions?  ;)

>> >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?
>> 
>> Sounds very neat.  :)
>
>Which one - With the explicit hint or without it?

Sorry - I meant using minsize == maxsize sounds like a good idea. That way
applications can expect consistent behaviour inside and outside the DE, in at
least *one* respect!  :)

Michael