Hey all, I'd like to raise some attention on wip/wayland-tablet, especially the API changes it involves, and the possible behavioral changes that could be expected.
wl_tablet itself is not there yet, the last drafts are really solid, but currently relies on non-master branches all along the stack. Because I expect little to no changes, I feel it's safe to start proposing the extra API around, along with the X11 support. All API changes are held so far in the first commits, until: 58310d2 GdkDeviceTool: Add GdkAxisFlags info to tablet tools Some notes about the API: * The most notable addition is GdkDeviceTool, these are related to GDK_SOURCE_PEN/ERASER devices, and are created by GDK as new tools are used. GdkDeviceTool basically represents different physical pens, and work as a long-lived reference to it, the pointer can be used for comparisons as long as the device lives, and there's a getter for the serial ID, which may complement gdk_device_get_vendor/product_id() at the time of creating gsettings keys and whatnot. There can be multiple tools per GDK_SOURCE_PEN device, the GDK_SOURCE_ERASER device will only get the corresponding eraser tool. If this were to be done from scratch, I would go for a GDK_SOURCE_TABLET device (representing the tablet itself) with all tools (representing pens) depending on it. This is perhaps the one oddity as there's no other backward compatible way. * IMO It's time to admit that the GdkAtom-based axis getters API is kind of a failure and should be deprecated... it will require ad-hoc hacks in wayland (still in the todo), and the whole "hunt for driver specific strings" doesn't make it a too friendly API. Luckily, the GdkAxisUse based API wasn't deprecated, the enum is even expanded in the branch, adding a GDK_AXIS_DISTANCE, which we can honor at least on Wayland. * The branch also adds GdkAxisFlags (basically GdkAxisUse turned into flags), and gdk_device_get_axes(), these come out useful since on wayland the current tool determines the axes. This is a more direct mapping of the hw behavior, which the X11 driver tapped by just exposing all possible axes on all tools. This means that on Wayland slave devices' axes switch on the fly, similarly to how the master device changes axes on slave switch. And some thoughts on the final merge: The one "major" behavioral change between wayland and X11 here is that wayland tablets get their own pointer onscreen, so the mouse pointer stays unaffected. On GTK+3/X11, by default everything goes through the Virtual Core Pointer. When mapping this into GDK terms, there's 2 most obvious choices: - Creating a master device per tablet: This allows for setting per -tablet cursors, as wl_tablet allows, but it might require a bit of porting effort (esp. around simultaneous interaction scenarios, checking master devices, maybe setting per-device grabs). GTK+ itself is ready for that, so it would be ugly at worst, but not broken. - Creating tablets as detached slaves: This would be actually very similar to the GTK+2 days. Slaves don't have a cursor, so these shouldn't be honored, and users would need to gdk_window_set_device_events() manually for these in order to receive events at all. Overall a bit of a step back IMO. The branch goes for the first option, the scenario is hard enough to trigger, and apps slowly coming from the gtk+2 days should already have similar checks around to cater for pointer+extension devices. So this strikes me as least painful and most consistent with our GTK+3 story. The branch also cheats a bit, and sets the master keyboard as the paired keyboard for all per-tablet master pointers, just so events have meaningful modifiers. This is somewhat inconsistent wrt gdk_device_get_associated_device() on master devices (each of these supposedly pointing to the other, this will no longer be true for tablet devices). I doubt this will bring in any real problems, it is worth pointing out though. And that's it for now I think... opinions? Cheers, Carlos _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
