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 _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
