Re: Review: FULLSCREEN_MONITORS Hint

[Nathaniel Smith <njs pobox com>]

On Thu, Mar 06, 2008 at 07:04:32PM -0500, Dana Jansens wrote:
> On 3/4/08, Nathaniel Smith <njs pobox com> wrote:
> > On Tue, Mar 04, 2008 at 06:55:25PM -0800, Grant Patterson wrote:
> >  > Dana Jansens wrote:
> >  > >There are no other data.l[] elements, only 5.  That said, the data.s[]
> >  > > elements should be more than enough and allow for more things to be
> >  > > added in the future, but I realize every other hint exclusively uses
> >  > > data.l[].  Anyone else have an opinion about this?
> >  > >
> >  > I like the idea of using the 16-bit elements so there's room for expansion.
> >  > While I can't see any reason for this now, there might be some flags an app
> >  > would want to set to further define window manager behavior. Changed.
> >
> >
> > Oh, please don't, there are enough bizarre and surprising
> >  inconsistencies in the X world as it is.  (And this would require a
> >  whole new special case in at least my code.)
> >
> >  If you want future expandability, without using a new atom, then do it
> >  properly -- mark some fields as "if this field is non-zero, then
> >  discard the event" and some as "if this field is non-zero, then
> >  pretend the field is zero anyway", all that complex cruft.
> >  Alternatively, just accept that the way we do future expansion is by
> >  adding a new, extended atom, a la _NET_WM_STRUT{,_PARTIAL}...
> 
> This change was for the client message, which cannot be expanded in
> the future.  The property itself would remain CARDINAL 32bit typed.

Yes, that is one of the inconsistencies I was referring to.  (The
other is that every other message in the spec uses format=32.)

> It sounds to me like you misunderstood what was being made 16bit
> fields.

I don't *think* I did, and nothing you've said has made me think
otherwise?  I am using "expandability" in the general sense of "adding
new capabilities to the spec", not in the narrow sense of "adding more
bytes at the end of a property".

Ultimately either approach works, of course, and I don't expect my
having to write extra code in my event handling routine[1] to weigh
*very* heavily on others (though it does seem to be the only data
point being advanced ATM).  But someone has to speak up in the name of
taste and consistency; it's not like X has such an abundance of it to
spare.  (At the very least, if we do make it a 16-bit message
can we put a capital-letter warning in the spec pointing this out?
Implementors are just going to bark their shins on it otherwise, and
setting people up for hurt shins seems mean to me.)

[1] The code I have now can only handle client messages with format 32
because, well, that's the only sort of client message that actually
exists in the wild ATM.

-- Nathaniel

-- 
Electrons find their paths in subtle ways.