Your hurt-shins argument convinces me, someone who's new to the OSS world and could use all the consistency he can get! I can't see anything on the horizon that would warrant leaving extra space in the message, and the worst-case scenario (we'll have to add another client message later) isn't that bad. So 32-bit all around?
Nathaniel Smith wrote: > On Thu, Mar 06, 2008 at 07:04:32PM -0500, Dana Jansens wrote: >> 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. > > 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 > _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list