On Wed, Nov 11, 2015 at 12:32:24AM +0100, Carlos Garnacho wrote: > Hey, > > On Tue, Nov 10, 2015 at 10:47 PM, Peter Hutterer > <peter.hutte...@who-t.net> wrote: > > On Fri, Nov 06, 2015 at 09:26:47AM +0800, Jonas Ådahl wrote: > >> On Thu, Nov 05, 2015 at 12:21:29PM -0600, Derek Foreman wrote: > >> > On 04/11/15 07:24 PM, Jonas Ådahl wrote: > >> > > On Thu, Nov 05, 2015 at 08:44:57AM +1000, Peter Hutterer wrote: > >> > >> On Wed, Nov 04, 2015 at 09:57:35AM +0800, Jonas Ådahl wrote: > >> > >>> On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote: > >> > >> [...] > >> > >>>> + <event name="frame" since="5"> > >> > >>>> + <description summary="end of a pointer event sequence"> > >> > >>>> + Indicates the end of a set of events that logically belong > >> > >>>> together. > >> > >>>> + A client is expected to accumulate the data in all events > >> > >>>> events > >> > >>>> + within the frame before proceeding. > >> > >>>> + > >> > >>>> + All wl_pointer events before a wl_pointer.frame event belong > >> > >>>> + logically together. For example, in a diagonal scroll motion > >> > >>>> the > >> > >>>> + compositor will send an optional wl_pointer.axis_source > >> > >>>> event, two > >> > >>>> + wl_pointer.axis events (horizontal and vertical) and finally > >> > >>>> a > >> > >>>> + wl_pointer.frame event. The client may use this information > >> > >>>> to > >> > >>>> + calculate a diagonal vector for scrolling. > >> > >>>> + > >> > >>>> + When multiple wl_pointer.axis events occur within the same > >> > >>>> frame, > >> > >>>> + the motion vector is the combined motion of all events. > >> > >>>> + When a wl_pointer.axis and a wl_pointer.axis_stop event > >> > >>>> occur within > >> > >>>> + the same frame, this indicates that axis movement in one > >> > >>>> axis has > >> > >>>> + stopped but continues in the other axis. > >> > >>>> + When multiple wl_pointer.axis_stop events occur within in > >> > >>>> the same > >> > >>>> + frame, this indicates that these axes stopped in the same > >> > >>>> instance. > >> > >>>> + > >> > >>>> + A wl_pointer.frame event is sent for every logical event > >> > >>>> group, > >> > >>>> + even if the group only contains a single wl_pointer event. > >> > >>>> + Specifically, a client may get a sequence: motion, frame, > >> > >>>> button, > >> > >>>> + frame, axis, frame, axis_stop, frame. > >> > >>>> + > >> > >>>> + The wl_pointer.enter and wl_pointer.leave events are logical > >> > >>>> events > >> > >>>> + generated by the compositor and not the hardware. These > >> > >>>> events are > >> > >>>> + also grouped by a wl_pointer.frame. > >> > >>> > >> > >>> I like the idea of wl_pointer.frame in general, but I don't like this > >> > >>> part, because enter/leave really shouldn't be seen as pointer events > >> > >>> at > >> > >>> all. For example a window closing because of whatever reason will > >> > >>> result > >> > >>> in a wl_pointer.enter on the window that happened to be below. This > >> > >>> has > >> > >>> nothing to do with the pointer device, it is just about the pointer > >> > >>> focus. > >> > >>> > >> > >>> The reason you have made the enter/leave events be dispatched state > >> > >>> events to the frame event is, as you wrote above, to make it possible > >> > >>> for extensions to extend the enter/leave events, but they can > >> > >>> already do > >> > >>> so by making those extensions latched events appending state to the > >> > >>> enter or leave events. If we need to make some extension that adds > >> > >>> something to receiving or loosing focus, I think they'd be worth > >> > >>> their > >> > >>> own events with their own semantics. > >> > >> > >> > >> I understand it's not pretty for the enter/leave semantics, but I'd > >> > >> argue > >> > >> that it's potentially more confusing to have it to apply to all > >> > >> wl_pointer > >> > >> events except enter/leave than just apply to all. > >> > > > >> > > I disagree. I see wl_pointer.frame to be the grouping of pointer > >> > > events. > >> > > The enter/leave are pointer *focus* events, and have nothing in > >> > > particular to do with actual events from the pointer, making them > >> > > different enough to make me feel they have very little in common with > >> > > the rest of the events, thus are not suitable to be framed by > >> > > wl_pointer.frame. > >> > > >> > They're quite similar in that they're coming from the same protocol > >> > object. What's the benefit in having a separate frame mechanism for > >> > enter/leave should they need extension later? > >> > > >> > To me the focus events feel more like "seat" events than pointer events, > >> > but they're still coming from the pointer object... > >> > >> The benefit is a clearer semantical difference, i.e. that enter/leave > >> are *not* regular pointer events, they are strictly focus events, and > >> that wl_pointer.frame frames events from the actual pointer. > > > > I think at this point the semantics of the frame in regards to enter/leave > > is the only thing preventing this from being finished. Any chance we can > > come to a conclusion here? Carlos, any opinion from the GNOME side of things > > on the semantics? You already gave your rev-by but any specific comment on > > this here? > > FWIW, I do see the usefulness of having enter/leave under the same > frame semantics. When we get around at doing an extension protocol to > communicate more details about the current input device to apps, I'd > expect the related event to be sent 1) when the pointer enters the > surface and 2) anytime after when the user changes to another device. > Of course nothing prevents this event from being sent together with > both .enter and .frame, but strikes me as redundant. > > I kind of see jonas' point, enter/leave are in the fine line between > seat and pointer. IMHO, focus accounting could be seen as belonging to > the seat (i.e. there's only one pointer focus per seat), but the > events do belong on the device as these determine all the other events > to be expected. It'd make sense to have all pointer events stick to > the same event coalescing then. > > > > > Unfortunately, we're on too many different continents to make a jousting > > tourney worthwhile. > > Hope one more opinion helps somewhat...
It does make it clear that grouping both device events and focus events with the same frame event is a more popular opinion than not so I guess it's more or less decided what the conclusion is. Jonas > > Cheers, > Carlos _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel