On 2015-08-29 13:39 (+0200), David Evans wrote:
On 8/28/15 2:59 PM, Krzysztof Kosiński wrote:
The long term solution would be to use the Quartz backend of GTK instead of the X11 backend on the Mac. However, the prerequisite is porting Inkscape to GTK3 and ironing out all the bugs that will cause.
Nonetheless, it appears, at this point, that this is something that really needs to be done since the upstream gtkmm developer has indicated that he considers gtkmm-2.24 an "ancient deprecated version" that he doesn't care to maintain further and has specifically put Inkscape on notice to port to the current GTK3 version ASAP[1][2].
I note that the current experimental GTK3 code builds on Mac (using MacPorts at least) using either the X11 or quartz backends and seems to function at a basic level although I am not an expert Inkscape user by any means.
What is the official status of this GTK3 port and what will it take to bring it up to snuff as the preferred build? Is there currently any concerted effort in this regard and if so who is/are the lead developer(s) for this effort?
If someone wanted to help, where would he/she start?
Some of the known (blocking) issues wrt using the Quartz backend of Gtk+ with official Inkscape packages for OS X:
Inkscape's canvas (GTK2, GTK3) ============================== All Inkscape builds (stable, trunk) using Gtk+'s Quartz backend suffer from canvas redraw/refresh issues (try using a Quartz-based build with all the GUI elements hidden - the keyboard shortcut to toggle this mode on/off is 'Shift+F11'). GTK3-based builds expose quite bad flickering on top of that.
Also listed among the known issues here: http://wiki.inkscape.org/wiki/index.php/Notes_on_Packaging_for_OS_X#2014:_os... https://code.launchpad.net/~suv-lp/inkscape/osxmenu
Screen recordings: https://inkscape.org/en/gallery/6314/
Data exchange via native clipboard (GTK2, GTK3) =============================================== Current state with Gtk+/Quartz is even worse than with Gtk+/X11 (which is already limited to raster image formats, besides text). AFAIU mostly an upstream issue first (possibly requires implementation of backend-specific support in Inkscape too): https://bugzilla.gnome.org/show_bug.cgi?id=692123
OS integration (GTK3) ===================== In order to use GTK3's native support for OS integration (e.g. the global menu bar on OS X), Inkscape's internal menu / application code would need a major refactoring AFAIU. Using the external library gtk-mac-integration is (at least for the moment) still possible (it does support GTK3), but discouraged by its author (the library was written for GTK2 which does not have such internal support at all). An example of a GTK3 application which successfully uses GTK3's native support for the global menubar on OS X is current stable Gedit.
A GTK3/Quartz-based (self-contained, relocatable) Inkscape application bundle demo is available based on the osxmenu branch (DMG, requires OS X 10.7 or later). This demo app bundle uses gtk-mac-integration-gtk3 for the global menu bar (due to Inkscape's lack of support for native GTK3 features).
Extended input devices (GTK3) ============================= Current (stable) GTK3 Quartz backend lacks any support for pressure-sensitive input devices. A related patch which had landed earlier in GTK2 is limited (stability is only expected if used with applications launched as regular osx application bundle; unclear whether anything but Wacom is actually supported; IIRC from MyPaint-related discussions, there seem to be differences e.g. to the X11-based feature wrt the number (or quality) of received events/data (?)). A follow-up patch for GTK3 is still in bugzilla (no recent activity): https://bugzilla.gnome.org/show_bug.cgi?id=695701
GTK3 / GNOME ============ GTK3 (to a larger extent than GTK2) seems to increasingly rely on system services commonly available on Linux DEs (e.g. dbus, gvfs) which - AFAICT unlike the Win32 backend - do not have a native OS X port (in glib, GIO, gvfs, etc.) yet, and which are a pain for packaging if one aims for a self-contained relocatable application package which does not require to use an installer (in order to install what is required to auto-launch/manage launchd-supported services as required dependencies outside of the application bundle).
... (not an exhaustive list).
Regards, V
Sorry for my ignorance concerning the current state of affairs.
Dave
[1] https://bugzilla.gnome.org/show_bug.cgi?id=752797 [2] https://git.gnome.org/browse/glibmm/commit/?id=7d2e6b84c6e4e5a371887f98f42b5...