Re: Still need a hint for undecorated windows



On Monday 25 July 2005 19:50, Elijah Newren wrote:
> On 7/25/05, Bill Haneman <Bill Haneman sun com> wrote:
> > >Well, this probably isn't the answer you were looking for, but no, the
> > >only language in the spec is that the MWM hints are deprecated.
> >
> > This is, as you suggest, totally unhelpful.
>
> At least it doesn't cause damage, though, which would be the result of
> official support of allowing apps-may-dictate-policy in the spec.

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.

> , 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 
docs that describe a toolkit you are not targetting is the sane rational way 
to get the API you need.

- ajax

Attachment: pgppcDhlfrUUu.pgp
Description: PGP signature



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