Re: Still need a hint for undecorated windows

[Bill Haneman <Bill Haneman Sun COM>]

Hi Havoc:

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.

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 know that "self decorating" 
windows end up imposing their own resizing/dragging behaviors in 
apparent violation of this, but as self-decorating windows are 
controversial anyway, I don't think we should be too concerned about 
that.  It does mean that there are behavioral aspects to "truly 
undecorated" windows.

> Anyway, we have the MWM hint which is "I am semantic type XYZ, but omit
> any window decorations you would have added." This is there in
> implementations and will remain, but it's basically a nonsense thing to
> say to the WM. It just doesn't make any sense because any reason we can
> come up with for omitting decorations _also has implications for a dozen
> other behaviors_.
>  
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 .

> A WINE window should not be treated exactly the same as TYPE_NORMAL, and
> neither should an onscreen keyboard.
>  
Of course.  But those two should not be the same WM TYPE either!

> Again, look at:
> http://mail.gnome.org/archives/wm-spec-list/2005-July/msg00003.html
>
> Some key points:
>
> - there is already a supported way to "just turn off decorations"
>   (MWM hint)
> - but this hint makes no sense as the actual fix, because it dials
>   in inherent, inevitable bugs that can't be addressed in either app
>   or WM
>
> The reason is that you must set up all the window behaviors in *one
> place* to get them right. Either the app (aka toolkit) does it and the
> WM is just a display engine, or the WM does it and the app just
> communicates the high-level semantics. "Both do half of it" results in
> incoherent nonworking unfixable buggy software.
>  
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.

> And that's why on no planet where anybody has a clue should the spec
> include *both approaches*. The spec currently assumes the WM does it.
> The only way to let the app do it would be to rip-and-replace the whole
> approach of both EWMH and ICCCM and write new specs that were wholly
> nonsemantic. Leaving it ambiguous who defines window behavior is crazy.
>
> So again:
>
> - yes there is a short term fix, and has been for years, which is 
>   the MWM hint
> - but no this is not a real fix, and no it does not make sense, 
>   so app authors do have an interest in a better fix
>
> Another way to understand why we need to pick one approach (either apps
> define or WM defines):
>
> - to correctly implement window behavior, you must understand the full 
>   picture. If the toolkit has half the understanding and guesses half,
>   and the WM has half the understanding and guesses half, then it's 
>   impossible to make the overall system work correctly.
>
> Which comes back to, *window behavior must be defined in one place*
>  
But not "one dimensionally".

Bill

> It's just reality of the software engineering that it has to be clear
> which code module is doing which things, and the interfaces between
> modules have to make sense.
>
> Havoc
>
>
>