<html>
    <head>
      <base href="https://bugzilla.gnome.org/" />
    </head>
    <body><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> changed
              <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>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
                
           </td>
           <td>mclasen@redhat.com
           </td>
         </tr></table>
      <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#c1">Comment # 1</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>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

2) gdk_device_update_tool just stores a pointer to the passed-in tool without
using gdk_device_ref/unref - is that safe ?

3) Maybe more concerning, _gdk_wayland_seat_remove_tool appears to be cxalling
g_object_unref on a GdkDeviceTool

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 ?

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 ?

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 ?

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?)</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>