<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add tablet support"
href="https://bugzilla.gnome.org/show_bug.cgi?id=764385#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add tablet support"
href="https://bugzilla.gnome.org/show_bug.cgi?id=764385">bug 764385</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=mclasen%40redhat.com" title="Matthias Clasen <mclasen@redhat.com>"> <span class="fn">Matthias Clasen</span></a>
</span></b>
<pre>(In reply to Matthias Clasen from <a href="show_bug.cgi?id=764385#c1">comment #1</a>)
<span class="quote">> Some initial impressions from looking over the branch:
>
> 1) Do we forsee ever adding properties to GdkDeviceTool ? In that case, it
> might be better to make it an object now, instead of a boxed type</span >
Fixed in the branch
<span class="quote">> 2) gdk_device_update_tool just stores a pointer to the passed-in tool
> without using gdk_device_ref/unref - is that safe ?</span >
Fixed
<span class="quote">> 3) Maybe more concerning, _gdk_wayland_seat_remove_tool appears to be
> cxalling g_object_unref on a GdkDeviceTool</span >
Fixed
<span class="quote">> 4) The docs for ::tool-changed say it is emitted on proximity-in/out - what
> happens if I simply switch between two different pens - I guess it is
> assumed that there will always be proximity events around such a change ? Is
> that guaranteed ?</span >
This was answered
<span class="quote">> 5) Related to the previous point, I see a call to gdk_device_update_tool in
> tablet_tool_handle_proximity_in, but not in
> tablet_tool_handle_proximity_out. Oversight ?</span >
Fixed
<span class="quote">> 6) Is there always going to be a 1:1 relationship between devices and tools
> ? Could one imagine a fancy 'multi-pen' tablet that handles more than one
> tool simultaneously ?</span >
Answered
<span class="quote">> 7) Grepping for GDK_SEAT_CAPABILITY_TABLET_STYLUS in gdk/*/*.c comes up
> empty - I would have expected seats to expose that capabability (and
> associated master devices) now ? Also, should that name be shortened to
> GDK_SEAT_CAPABILITY_TABLET, maybe ? The stylus is just a tool, after all
> (right?)</span >
Decided to not do this for now.
Branch looks good to me now, fwiw.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>