On 3/4/08, Nathaniel Smith <[EMAIL PROTECTED]> 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.
It sounds to me like you misunderstood what was being made 16bit
fields.
dana
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
