Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

On Wed, 2005-08-03 at 10:57 +0100, Bill Haneman wrote:
> Havoc Pennington wrote
> 
> >Right now the way we do the MWM hint is to use the same behavior as the
> >specified semantic type, and just remove decorations. But often this
> >behavior is wrong; for example, I don't think a window of TYPE_NORMAL
> >with no decorations is really what you want for an onscreen keyboard.
> >TYPE_NORMAL means a "main application window" basically.
> >  
> >
> Can you give some other examples?  Onscreen keyboards shouldn't be 
> TYPE_NORMAL anyway, as  you point out, so actually onscreen keyboards 
> (of the type GOK creates, anyhow) aren't IMO customers for the 
> "undecorated" hint.

Other examples of undecorated windows I know of are WINE and
XMMS/Gkrellm (whether those two are the same I guess is debatable),
maybe the thing Adam posted, konfabulator-ish things, etc. I know there
are quite a few people have brought up over the years.

> In a sense, "undecorated" does specify behavior - it means "noborder", 
> i.e. onscreen size == notional size, and it implies "don't minimize, 
> non-user-resizable, non-draggable". 

I'm not sure this is clear at all - e.g. Adam's example doesn't have
those properties, does it? He said it was like NORMAL except for lacking
decorations. In any case undecorated MWM hint does not make metacity add
any of those behaviors you mention.

I'm not against some hint that includes undecorated and some of this
other stuff, as long as someone can spell out the use-cases.

> I think that it makes sense for behaviors to be a composite of different 
> behavioral attributes, rather than requiring that behavior be a 
> one-dimensional thing based on WM_TYPE .

Agreed, and this is already the case (it's why we have the state stuff
and various other hints like the on-all-desktops hint or skip-taskbar
hint).

It's just case-by-case whether it makes more sense to do it as a
WINDOW_TYPE or something else.

> Sure, which is IMO an argument in favor of supporting an 'undecorated' 
> hint in the WM, so that the app doesn't have to do it, and so that the 
> 'undecorated' behavior subset may be combined with the other behavioral 
> aspects of WM_TYPE.

I don't see this argument unless we can first describe a window type's
ideal behavior without reference to the WM spec, and see that for
logical reasons the type's ideal behavior is identical to the ideal
behavior of some WINDOW_TYPE minus decorations. For example, a TYPE_DOCK
that wants to be below other windows logically behaves exactly like
TYPE_DOCK, but with an extra flag set. So we do a BELOW hint as a flag.

But an OS X style drawer on the side of a window does _not_ logically
behave exactly like any existing type minus decorations; it would make
more sense in my mind as a TYPE_DRAWER than as TYPE_NORMAL plus some
random flags.

This is just an implementation issue. But in my mind the way you figure
it out is first know what kind of window type and window behavior you're
trying to provide, and then figure out the simplest and most robust way
to implement it.

If someone wants to implement drawers as a stack of hacks in the
meantime that's fine too, but I think the spec should be about
documenting a good way to do it.

Havoc