The major problem with PropertyNotify events, or with having generalized properties of any kind, is that they are too much like polled interrupts rather than vectored interrupts. You get the event, but you then have to poll to see which thing changed.
Also, the protocol design seems to be more like RPC than "read a struct". I would guess we will identify a dozen or so things that other pieces of the system will want to keep an eye on, so you can write what we now know as panels, and then set up callbacks you can ask for to be notified when they change, and some inbound protocol to make requests like Iconify or Raise. Like what EWMH and libwnck is for today. I have a draft of this in process that I promised a while back. I will see if I can't get it cleaned up and posted in the next couple of days. If you have argument marshalling already in the protocol for other purposes, there is little reason not to deliver an integer as int rather than a string that everyone has to have parsing code for. Definitely on board with UTF-8 as the only choice for text, though. On 01/18/2011 11:50 AM, Bill Spitzak wrote: > I expect Wayland will add a "attach this blob of data to this window+key" > similar to X window properties, for IPC to the compositor and other software. > > The question is whether software is going to be required to keep these things > up to date for information that Wayland must know anyway. Requiring the > compositor to track the focus changes and set an attribute on a window so > other programs can see which window has focus seems wasteful and unreliable, > since Wayland is using this information itself anyway. > > But rather than adding a "give me the focus window" api, it may make a lot of > sense for Wayland to automatically update a set of properties. Ie there would > always be a "which window has focus" property without the compositor having > to set it. Instead Wayland sets it internally. Sort of like the /proc > filesystem. > > PS: Please make the properties be UTF-8 text only (well actually byte streams > with some non-enforced encouragement that they be UTF-8 text). No data types. > Programs can parse and this is much more user and programmer friendly. > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
