Native Mac OSX Application for Inkscape
Ultimately, we want signed DMG (non-X) releases of Inkscape 1.0. This is a top request from many of our users and sponsors.
This means we need to compile Inkscape with Quartz but without X11 and against Gtk3 instead of Gtk2, with current Inkscape master. Since it will still use Gtk this isn't "Native" in the truest sense of the word, but it will adhere closely to the standard Mac user experience.
This is a master issue for outlining the problem space and linking all bug reports relevant to creation of a native Mac package. We don't need to link every bug related to Mac, just issues involving the packaging itself, feature development needs, and severely critical bugs.
Breakdown
From what I have gathered, it sounds like we can break this problem up into a few discrete pieces:
(1) Legacy package maintenance
Legacy packages include the various XQuartz (X11-based) packages currently in use for distributing the 0.92x version of Inkscape. There have been several different packaging solutions, including through MacPorts and HomeBrew. Many of our current bug reports and discussions are about these legacy packages; some issues will still be relevant with a native package, some won't.
(2) Dependency versions
Gtk and assorted libs are moving targets, version-wise. Tracking the bleeding edge can be problematic, suggesting using some defined snapshot of them, possibly even shipping them ourselves in the image. This sounds like something that needs more exploration to find the most maintainable solution that gives users the right balance of installation convenience and support.
(3) CMake packaging improvements
Paths to the share folder, and probably other platform specific stuff could be rolled into the CMake rules, like we've done with Win32. I don't know what the state of this is, but I expect the more we can properly bake into our core CMake scripts, the more maintainable this all will be longer term.
(4) UI/UX glitches and styling issues
Things like the behaviors of popup menus and stuff need tweaking. Probably a lot will end up being Gtk upstream troubles, which we'll either need to fix ourselves and send patches upstream, or add workarounds in Inkscape itself. In either case, we need to build a list of upstream bugs to keep track of.
In addition to behavioral problems are also going to be some stylistic oddness - things that work ok functionally but just don't "look" right on a Mac: Spacing of widgets, appearance of custom UI elements, order of things in menus, etc.
(5) Native packaging maintenance efforts
If I understand right, Valerioa (and capin maybe?) have worked thorough a lot of the actual problems in getting a native (or native-looking?) build working. Sounds like it needs some productization attention though, to reduce the number of "hacky" steps needed, and maybe get all the fixes integrated properly into the mainline codebases.
(6) Desktop integration
- Preferences handling
- Application and user data files
- Shared resources
- Mapping the XDG spec to the conventions used on Mac OS X
- Default paths
- Copy and Paste
- Native menu integration (e.g. file and print)
(7) External tool integration
For file format conversion, filters, and extensions we use various 3rd party tools, e.g. Ghostscript, GIMP, etc. For tools that have good Mac ports we should integrate with them directly, rather than running them on the command line. For tools that do not have Mac ports, we should look at a) replacing them with equivalent functionalities already present on Mac, b) creating and providing our own packages of these tools, or c) including them in the DMG bundle (which we generally try to avoid to keep file size down).
(8) Testing
There are going to be several different angles to testing. The packaging correctness and general installation experience need tested. The basic software functionality needs acceptance-level testing. The UI needs UX testing for fit and function with the OS. Bug reports on all discovered issues need filed with good write ups, appropriately tagged, and prioritized.
(9) Maintenance documentation
A "paint by numbers" style document of the procedure for producing packages when a new Inkscape release is put out, to save future packaging volunteers time and confusion. These directions will need to be kept up to date and authoritative.
(10) Signing
The end result package needs to be formally signed by us. I'm told there is a $99 cost to get a Developer subscription, which lasts 4-5 years and provides a signing cert that can be used to sign the .app using the codesign
command. For listing the app in the MacApp store there is an annual renewal fee. Some additional research should be done to see if there's any other steps needed.