Re: Still need a hint for undecorated windows

[Elijah Newren <newren gmail com>]

On 7/25/05, Adam Jackson <ajax nwnk net> wrote:

> Do note that decorations and window functions are orthogonal, and that
> asking to be borderless means you've accepted that your life will be hard.
> When it becomes sufficiently hard that users complain, you've had enough
> usage experience to accurately defined the semantics you want, so only
> then are you armed with enough information to extend the netwm spec.
> 
> Cart.  Horse.  One of these goes first.
> 
> > That said, I agree we have a problem that not enough semantic types
> > are covered in the spec.  But the right way to converge to a
> > consistent solution is to add more semantic hints (and I think you had
> > some good cases for adding more)
> 
> How are these semantic hints supposed to be developed before they land in > the spec?  All new semantic types that affect decoration can be emulated
> (perhaps poorly) by starting with no decoration and doing your own for a
> while.

Very good points.  I think it comes by, for example, having some WMs
support those deprecated hints (currently, I believe most do)--such
apps really only need one WM to do such developing and testing.  I
also think that it comes with nonstandard extensions that may later be
adopted (e.g. _KDE_NET_WM_USER_CREATION_TIME, _METACITY_VERSION, etc.)

> > , not to adopt a short term "fix" that
> > sends us down the wrong path (besides, I'll note that we already have
> > a short term fix--most WMs support these deprecated hints for now
> > anyway and will probably continue to do so for the forseeable future)
> 
> If this behaviour is desirable, why isn't it in the spec?  Hide it behind
> SHOULD or MAY or whatever if you like, but write it down somewhere.  When > app developers go to write new code, and need a wm interaction, they think
> to look in ICCCM and net-wm.  Obscure Motif docs are not considered useful
> sources of information for writing new qt or gtk apps.  Obviously looking in

(I'll just note that there's a gtk_window_set_decorated() and I'm
guessing qt has something similar though I haven't verified--so app
authors wouldn't have to look in obscure motif docs)

> docs that describe a toolkit you are not targetting is the sane rational way
> to get the API you need.

Perhaps people are pointed to such obscure docs because there's a
feeling that the majority of the usage of such hints is abuse (Tuomo
would probably say all such uses are)...  ;-)

Besides, supporting workarounds tends to defeat forward progress. 
Granted, I understand that workarounds are needed when progress is not
far enough along yet, but that's what the support of deprecated hints
is for.


Cheers,
Elijah