<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 30 March 2013 05:31, Matthias Clasen <span dir="ltr"><<a href="mailto:matthias.clasen@gmail.com" target="_blank">matthias.clasen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here are a few questions/observations I had while studying the protocol docs:<br>
<br>
- The use of serials in events seems a bit inconsistent. Most<br>
wl_pointer events have serials, but axis doesn't. wl_keyboard<br>
enter/leave events do. wl_data_offer.enter does, but the corresponding<br>
leave/motion events don't. Is there a rationale for this ?<br></blockquote><div><br></div><div style>Yes: serials are used for events which can be used to trigger other events, e.g. setting the pointer, launching a popup, starting a drag, etc. This is not something you tend to do from scroll or data events.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Various input events have a time field. The spec doesn't really say<br>
anything about this. What is it good for, and what units are these -<br>
monotonic time ?<br></blockquote><div><br></div><div style>Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- It looks like I can't trigger a popup from a key or touch event,<br>
because set_popup requires a serial that corresponds to an implicit<br>
pointer grab. That is sad, I like the menu key...<br></blockquote><div><br></div><div style>Yeah, that'd be great to fix!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Still on popups, I don't see a way for the client to dismiss the<br>
popup, or is that handled by just destroying the surface ?<br></blockquote><div><br></div><div style>Indeed, just destroy the surface or attach a NULL buffer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Buffer transformations - fun. How do these relate to each of the following ?<br>
- resize edges<br>
- transient offset<br>
- buffer attach x/y<br>
- input/opaque/damage regions<br>
- surface x/y in motion events<br></blockquote><div><br></div><div style>All the latter occur on surfaces rather than buffers, so are unaffected. Buffer transforms are meant to support situations like where your screen is rotated 90°, and your client can also render rotated in order to avoid that extra blit. So it doesn't affect the event pipeline at all, only the display pipeline.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- What is a wl_touch.frame event ? Weston doesn't seem to generate those...<br></blockquote><div><br></div><div style>It's meant to indicate a natural boundary between touch events, à la a full EV_SYN. So you'd send touch events for every finger down, followed by frame, at which point you could perform gesture processing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- The wl_pointer interface seems to be a bit weak wrt to device<br>
properties. I would at least expect to learn about the number of<br>
buttons and right-handed vs left-handed, etc.<br></blockquote><div><br></div><div style>wl_pointer is an aggregation of mice, not a single mouse, so we can't necessarily sensibly expose number of buttons. For right vs. left-handed, I'd expect the compositor to do the swap and clients never have to worry about it. If you want to expose that configuration, that should occur through private protocol.</div>
<div style><br></div><div style>Cheers,</div><div style>Daniel</div></div></div></div>