[PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

[Peter Hutterer]

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?

Unfortunately, we're on too many different continents to make a jousting
tourney worthwhile.

Cheers,
   Peter