Re: Still need a hint for undecorated windows



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]