Hi Daniel,
Thanks for the review. I'll reply to a few select pieces, anything skipped
is something I'll just fold into the next diff.
On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote:
> Peter, Stephen,
>
> On 6 November 2015 at 04:24, Peter Hutterer wrote:
> > This is the revamped
On Mon, Nov 16, 2015 at 12:07:12PM +, Daniel Stone wrote:
> Hi Jonas,
>
> On 16 November 2015 at 11:59, Jonas Ådahl wrote:
> > On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote:
> >> On 6 November 2015 at 04:24, Peter Hutterer
> >> wrote:
> >> > +More than one tablet may exis
On Mon, Nov 16, 2015 at 11:55 AM, Carlos Garnacho wrote:
> It's probably worth pointing out that his concerns are moot, there is
> no blinking, or rather, has an easy solution in compositors.
>
> When a tool physically enters in proximity over a surface, the cursor
> should be effectively invisib
Hey,
On Mon, Nov 16, 2015 at 8:04 PM, Daniel Stone wrote:
> Bill,
>
> On Monday, 16 November 2015, Bill Spitzak wrote:
>>
>> There is a need to distinguish proximity-out from exit events. It is quite
>> possible to move the stylus so that the focus enters another client without
>> doing a proxim
Bill,
On Monday, 16 November 2015, Bill Spitzak wrote:
> There is a need to distinguish proximity-out from exit events. It is quite
> possible to move the stylus so that the focus enters another client without
> doing a proximity-out. Clients are interested in distinguishing these.
>
This is tr
There is a need to distinguish proximity-out from exit events. It is quite
possible to move the stylus so that the focus enters another client without
doing a proximity-out. Clients are interested in distinguishing these.
I really feel the best method is to say a "seat" has a keyboard focus and a
Hi,
On 16 November 2015 at 13:27, Carlos Garnacho wrote:
> On Mon, Nov 16, 2015 at 12:21 PM, Daniel Stone wrote:
>> Can we please enforce a strict bracketing of down/up occurring in
>> matched pairs inside of proximity_in/out? So, the total event stream
>> would be:
>> - proximity_in
>> -
Hey :),
On Mon, Nov 16, 2015 at 12:21 PM, Daniel Stone wrote:
> Peter, Stephen,
>
> On 6 November 2015 at 04:24, Peter Hutterer wrote:
>> This is the revamped version of the tablet protocol for graphics tablets
>> (e.g. Wacom tablets). Too many changes from the last version (a year ago or
>> so)
Hi Jonas,
On 16 November 2015 at 11:59, Jonas Ådahl wrote:
> On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote:
>> On 6 November 2015 at 04:24, Peter Hutterer wrote:
>> > +More than one tablet may exist, and device-specifics matter. Tablets
>> > are
>> > +not represented by a
On Mon, Nov 16, 2015 at 11:21:36AM +, Daniel Stone wrote:
> Peter, Stephen,
>
> On 6 November 2015 at 04:24, Peter Hutterer wrote:
> > This is the revamped version of the tablet protocol for graphics tablets
> > (e.g. Wacom tablets). Too many changes from the last version (a year ago or
> > s
Peter, Stephen,
On 6 November 2015 at 04:24, Peter Hutterer wrote:
> This is the revamped version of the tablet protocol for graphics tablets
> (e.g. Wacom tablets). Too many changes from the last version (a year ago or
> so), so I won't detail them, best to look at it with fresh eyes.
Thanks a
On Sun, Nov 15, 2015 at 11:50:26PM +, Auke Booij wrote:
> On 6 November 2015 at 04:24, Peter Hutterer wrote:
> > Signed-off-by: Peter Hutterer
> > ---
> > This is the revamped version of the tablet protocol for graphics tablets
> > (e.g. Wacom tablets). Too many changes from the last version
On 6 November 2015 at 04:24, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> This is the revamped version of the tablet protocol for graphics tablets
> (e.g. Wacom tablets). Too many changes from the last version (a year ago or
> so), so I won't detail them, best to look at it with
On Fri, Nov 13, 2015 at 10:17:15PM +0100, Carlos Garnacho wrote:
> Hey,
>
> On Fri, Nov 6, 2015 at 5:24 AM, Peter Hutterer
> wrote:
> > Signed-off-by: Peter Hutterer
> > ---
> > This is the revamped version of the tablet protocol for graphics tablets
> > (e.g. Wacom tablets). Too many changes f
Hey,
On Fri, Nov 6, 2015 at 5:24 AM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> This is the revamped version of the tablet protocol for graphics tablets
> (e.g. Wacom tablets). Too many changes from the last version (a year ago or
> so), so I won't detail them, best to look at
On Mon, Nov 09, 2015 at 02:33:39PM -0800, Jason Gerecke wrote:
> On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak wrote:
> > Having read this more carefully, the cursor scheme absolutely will not work.
> >
> > The main problem is that the client may want to choose a cursor for a tool
> > based on the
On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak wrote:
> Having read this more carefully, the cursor scheme absolutely will not work.
>
> The main problem is that the client may want to choose a cursor for a tool
> based on the location at which it came into proximity. It cannot set this
> cursor unt
Having read this more carefully, the cursor scheme absolutely will not work.
The main problem is that the client may want to choose a cursor for a tool
based on the location at which it came into proximity. It cannot set this
cursor until after it gets the proximity event. If this desired cursor i
On Thu, Nov 5, 2015 at 8:24 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> This is the revamped version of the tablet protocol for graphics tablets
> (e.g. Wacom tablets). Too many changes from the last version (a year ago or
> so), so I won't detail them, best to look at it wi
Signed-off-by: Peter Hutterer
---
This is the revamped version of the tablet protocol for graphics tablets
(e.g. Wacom tablets). Too many changes from the last version (a year ago or
so), so I won't detail them, best to look at it with fresh eyes.
Makefile.am| 1 +
20 matches
Mail list logo
