On Tuesday 02 August 2005 18:26, Havoc Pennington wrote: > 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. Oh, but it is. Here's an example of a window type that wants to be undecorated that no one else has considered yet, and which was my motivation for bringing this up in the first place. OpenGL Multipipe is a toolkit for scaling GL applications to large displays. Since you may not have a 16-screen display handy while you're developing, it includes a simulation mode, where multiple non-fullscreen undecorated windows on one screen are tiled together to approximate the system you're going to deploy on. These windows want to behave exactly like top-layer, full-screen windows. And the desired semantics are almost exactly what you'd get with TYPE_NORMAL minus the decorations: place the window exactly where it asks, normal focus and stacking policy, only visible on the current virtual desktop, hide it when you hit Show Desktop, etc. And I think (IANA toolkit guy, or even an app guy) that's pretty close to what xmms wants too. There's no netwm hint for this; the spec really says "here's some semantic types, they replace the mwm hints", which means if there's no type you want then you're out of luck. You do see how that's hostile, right? OSK and other accessibility gadgets probably want something different, as do output-only glitter windows or Wine windows or whatever. Fine. How purist do you want to be here? Do you really want netwm to be the holy enumeration of all the valid semantic types? If you do so, you're actively inhibiting the creation and deployment of new types, and you still haven't documented the canonical way to get rid of the decorations. They're nearly orthogonal issues, but I would like to see at least one of them resolved. - ajax
Attachment:
pgpq0yjptsmBd.pgp
Description: PGP signature