Re: Still need a hint for undecorated windows

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Wed, 03 Aug 2005 20:16:58 -0400 Havoc Pennington <hp redhat com> babbled:

> I don't see this argument unless we can first describe a window type's
> ideal behavior without reference to the WM spec, and see that for
> logical reasons the type's ideal behavior is identical to the ideal
> behavior of some WINDOW_TYPE minus decorations. For example, a TYPE_DOCK
> that wants to be below other windows logically behaves exactly like
> TYPE_DOCK, but with an extra flag set. So we do a BELOW hint as a flag.
> 
> But an OS X style drawer on the side of a window does _not_ logically
> behave exactly like any existing type minus decorations; it would make
> more sense in my mind as a TYPE_DRAWER than as TYPE_NORMAL plus some
> random flags.
> 
> This is just an implementation issue. But in my mind the way you figure
> it out is first know what kind of window type and window behavior you're
> trying to provide, and then figure out the simplest and most robust way
> to implement it.
> 
> If someone wants to implement drawers as a stack of hacks in the
> meantime that's fine too, but I think the spec should be about
> documenting a good way to do it.

but the spec doesn't even let you know OF the hacks to do it - it doesn't say
"here is a "one hammer to solve all problems - UNTIL it's in the spec". it
claims to want to obsolete previous hints (like mwm) and thus implied "do not
use these" so a programmer goes "so how then do i do this?". a programmer may
not realise wm's will still support the mwm hints until the end of the world
comes because of legacy apps.

probably one of the best reasons to do this is: windows can do it. macos (9 and
below, and osx) can do it. programmers who have used those before know there are
simple ways to say to the os "i don't want decorations" and that' just what
happens. they may have a million reasons of their own as to why - but there is
no way a committee can divine all of these in advance. people can't wait on
writing their software until some debate has hashed itself out in wmspec
committee land years later - they want a solution - here and now. windows and
osx give them this solution already. according to wmspec this solution does not
exist in linux as its been obsoleted. (i am assuming borderless windows that are
under normal focus and other such control - not override-redirect).

competing os display systems provide the ability - thus if we are to make life
relatively sane for developers porting to x or supporting it, or migrating to it
or whatever - we should be able to provide similar features IF it is possible to
do it sanely. it is very possible to do this sanely - without an ounce of code
for anyone to write. simply formally bless the mwm hints as a "fallback
available until a semantic type has emerged from development of apps and added
to wmspec". we wouldn't have splashscreen, dialog and so on types if it wasn't
for software BEFORE the spec having demonstrated such window types as a unique
type. new types cant be magically divined here. leave the path open and catch up
later once a new type has emerged that isn't logically part of an existing type.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
裸好多                              raster deephackmode org
Tokyo, Japan (東京 日本)