Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

On Mon, 2005-07-25 at 23:57 +0100, Bill Haneman wrote:
> 
> If WMs don't support what apps want, apps will hack around this or vote 
> with their feet, finding WMs that allow them to do what they want 
> (however crazy we think that may be). 
>  This undermines the whole value 
> of having a spec.  If a spec is too rigid or limited, then it's almost 
> like having no spec at all - the whole point of a spec is having a 
> STANDARD, supported way of doing things.  The point of a wm spec is NOT, 
> IMHO, to tell application writers what kind of interfaces they 
> should/shouldn't be creating.

Not to restart the flamewar, but I am happy to add support for what apps
want as soon as someone can explain specifically what apps want.

"Undecorated" is not an explanation, see
http://mail.gnome.org/archives/wm-spec-list/2005-July/msg00003.html
for what needs spelling out.

For a window, we need to choose some behavior for all of those points
(and for a new kind of window, probably more points we haven't thought
of yet). We can't "not choose" - there has to be some behavior.

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.

The architecture of X11 dating from ICCCM is that the window types are
defined by the WM. The EWMH lets apps more richly specify window types
than they could historically with ICCCM only, which is somewhat helpful.

But to change away from semantic types really requires a high-level
choice that the WM is a display engine for the GUI toolkit (aka app).
This high-level choice would make much of the ICCCM and EWMH invalid and
irrelevant. I would code it that way if starting from scratch, to be
honest, but it's too late to do it that way for GNOME and KDE.

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

A WINE window should not be treated exactly the same as TYPE_NORMAL, and
neither should an onscreen keyboard.

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.

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*

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