Created attachment 238686 [details] [review]
Use doubles for the x,y mouse coordinates; however  x_root, y_root are still stuck as ints

Created attachment 238687 [details] [review]
A rough but working draft of pressure support

Created attachment 241615 [details] [review]
Draft 2 of pressure support

Attach an updated version of the patch, which fixes several bugs from draft 1.

Since it's been many months and I still haven't had time to fix this I am going to stop claiming it's ASSIGNED. The last patch here sometimes does not detect that the device has changed, I believe this is because the tablet proximity events gets delivered to a native window and doesn't make it this far into the event processing.

I think the shortest path to getting something useable will be to use the generic devices like GTK2 does instead of trying to detect different pens.

Downstream testing is happening in the MyPaint forums. I don't know the details, but it seems to be going well. Please can this patch be updated and merged as soon as possible?

https://community.mypaint.org/t/how-to-build-mypaint-on-mac-osx-without-macports/344/2

(In reply to Andrew Chadwick from comment #5)
> Downstream testing is happening in the MyPaint forums. I don't know the
> details, but it seems to be going well. Please can this patch be updated and
> merged as soon as possible?

The patch needs to be:

 * updated to use the seat and tablet API instead of the old device one
 * fixed to use the appropriate GTK coding style

Then we can review it and, after testing, merge it.

The patch in attachment 241615 [details] [review] is definitely not ready for landing in master.

(In reply to Emmanuele Bassi (:ebassi) from comment #6)

> The patch in attachment 241615 [details] [review] [review] is definitely not ready
> for landing in master.

But, regardless: thanks a lot for providing and testing it! It is very much appreciated. I don't have an OS X system, so I am really relying on this kind of cooperation.

Uhm, embarrassing that this went unreviewed for so long... Thanks Andrew for the ping, and Daniel for the patches.

One question about the platform? Do tablets in MacOSX "steal" the pointer cursor when drawing? If not, do those have a standalone visible cursor of their own?
Depending on the replies, I would suggest a different approach to supporting this in GTK3.

One thing is for sure, I think the code should be creating one GdkDevice with GdkDeviceType "slave" for every of those deviceID/uniqueIDs you see, and setting this specific slave device through gdk_event_set_source_device() in events.

The approach taken with gdk_quartz_device_core_set_active/unique() sounds too much like the old GTK2 days, where events from other devices would be selectively silenced if there's a tablet in proximity. Nowadays we prefer to represent the device hierarchy faithfully in GdkSeat/GdkDeviceManager and forward all events, so the upper layers can decide.

I don't know if I'll find time to work on this, and I don't have any expertise with OSX development or GTK, but I can tell you that tablets on OSX use the same cursor as the mouse.

Sorry I can't commit to this right now, and if I did have time, I'd have to spend it learning about Quartz and looking through the GDK code. But if someone else comes up with a patch, I'll gladly test it in the meantime.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new