<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add tablet support" href="https://bugzilla.gnome.org/show_bug.cgi?id=764385#c2">Comment # 2</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 <a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> Carlos Garnacho</a> <pre>(In reply to Matthias Clasen from <a href="show_bug.cgi?id=764385#c1">comment #1</a>) > 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 Right, IIRC it started like that in the early branches from from lyude and I didn't put much thought in it. I wouldn't expect much extra/non-static info ahead, but it'll be probably safer to make it a GObject anyway. > > 2) gdk_device_update_tool just stores a pointer to the passed-in tool > without using gdk_device_ref/unref - is that safe ? Oops yeah, ref/unref should probably happen there. > > 3) Maybe more concerning, _gdk_wayland_seat_remove_tool appears to be > cxalling g_object_unref on a GdkDeviceTool Good catch, that path is kind of untested... > > 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 ? This is kinda related to #6. I don't have multiple pens to try with, but I do expect proximity_out from an earlier tool before a newer one takes over. > > 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 ? It indeed is. > > 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 ? AFAIK, there were already such models, but those are mostly forgotten nowadays. It is true that the gdk layer couldn't cope as well with this case if it hw capability became trendy again, even though the wayland protocol itself can. > > 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?) Right, adding api to get devices with that capability should be in place with GdkDeviceManager API being deprecated. Agreed about the shortened name too. Will be working on those.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>