#Inkscape for mac 10.11.6 mac

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). For tools that have good Mac ports we should integrate with them directly, rather than running them on the command line. file and print)įor file format conversion, filters, and extensions we use various 3rd party tools, e.g.

#Inkscape for mac 10.11.6 mac os x

Mapping the XDG spec to the conventions used on Mac OS X.

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. 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. 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. In either case, we need to build a list of upstream bugs to keep track of. 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. Things like the behaviors of popup menus and stuff need tweaking. 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. Paths to the share folder, and probably other platform specific stuff could be rolled into the CMake rules, like we've done with Win32. 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. Tracking the bleeding edge can be problematic, suggesting using some defined snapshot of them, possibly even shipping them ourselves in the image. Gtk and assorted libs are moving targets, version-wise. 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. There have been several different packaging solutions, including through MacPorts and HomeBrew. Legacy packages include the various XQuartz (X11-based) packages currently in use for distributing the 0.92x version of Inkscape. Breakdownįrom what I have gathered, it sounds like we can break this problem up into a few discrete pieces: (1) Legacy package maintenance We don't need to link every bug related to Mac, just issues involving the packaging itself, feature development needs, and severely critical bugs. This is a master issue for outlining the problem space and linking all bug reports relevant to creation of a native Mac package. 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 means we need to compile Inkscape with Quartz but without X11 and against Gtk3 instead of Gtk2, with current Inkscape master. This is a top request from many of our users and sponsors. Ultimately, we want signed DMG (non-X) releases of Inkscape 1.0.