There's a branch/package by one of the devs that uses the native menu bar, native copy paste, drag and drop, and a few other things that make it feel like an actual Mac application. No clue why it isn't the official distribution, but it's been that way for years.

https://inkscape.org/cs/~su_v/galleries/

This hasn't been updated in 2 years.

I used to use that, and for my needs (pretty lightweight) it was fine.

Apparently the Inkspace developers were looking for this OSX-native-like version to be further developed before they'd promote it. Which is a shame, as release-early-release-often seems like it would have been a better idea. Oh well. :/

I ran into this issue and ended up using Affinity Designer. I was pleasantly surprised, it's actually quite comparable to Adobe Illustrator. It's not open source but at $50 much more reasonable than Adobe.

I second this. I've been using Affinity Designer for posters, UI mock-ups, icons, etc. Honestly, I can't use Inkscape at all. I find the interface highly bloated and the whole application generally slow.

How does Designer compare to Illustrator feature wise, and as far a usability? We already have Illustrator. Is it worth adding Designer?

I use the two side by side. At times I've found Designer's SVG support actually worked better than Illustrator. Illustrator is definitely faster but there are quite a number of useful pixel/recolouring features in Designer. Generally though the maturity and advanced features (mesh, isolate edit, Pathfinder!) eclipse what Designer brings to the table.

I was a long time Fireworks holdout, and Designer is maybe the closest in feel compared to Sketch or Illustrator (and they're copying each other better now).

All said, the bang for buck is great though, and UI is way easier than Inkscape I gotta say ;)

Just another data point: to me Affinity Designer actually seems to render much faster than Adobe Illustrator (on a 2015 Macbook Pro with Intel integrated graphics chipset).

Thanks for this: I didn't know about Designer, and was similarly let down by how less pleasant Inkscape was on Mac, coming from a lovely experience of it on Windows.

On Affinity Designer's site the price is $39.99, so even more reasonable.

20% off for a while with the launch of Affinity Photo for iPad at Apple's WWDC last week.

Affinity Designer development seems to have stalled. There are many requests for features that have been accepted but untouched for a year or two. My current showstopper: export to DXF.

I don't feel that "stalled" this is correct at all. They had a massive feature update via 1.5 in Oct. and 1.6 entered customer beta in May.

They just haven't shipped your preferred feature.

Ye gods, someone's pet peeve hasn't been touched in a year, and that means development has "stalled". Young people today.

Do you have any idea how long Illustrator users had to wait for artboards to land?

Are you playing with a cheap laser engraver off ebay?

One problem is that they are still on Gtk 2.x. There is so much work that was done in 3.x over the last 7 years that improves things.

Visual Studio for Mac is also Gtk 2.x, but they (Xamarin at the time) invested heavily in a custom Gtk fork as much of the hacks were not suitable upstream.

I just launched Inkscape, and noticed the port seems to be done! In Fedora 26, they ship Inkscape 0.92 which uses Gtk+ 3.

0.92.x does not use gtk3 (there is an experimental compile flag to use it, but it's still experimental)

You're both right. Fedora enables this option on F26.

rpm -qa | grep inkscape

inkscape-0.92.1-4.20170510bzr15686.fc26.x86_64

ldd /usr/bin/inkscape | grep gtk

libgtkmm-3.0.so.1 => /lib64/libgtkmm-3.0.so.1 (0x00007f12a6a2f000)

libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f12a4dbb000)

I wonder ... if they should do what Wireshark did, and abandon GTK for Qt.

Probably, and I've heard from some Inkscape devs that they'd like to. But it's a pretty massive project, which would directly result in the current developers being less proficient at the UI toolkit they use.

Qt is an easy sell on fresh projects, but switching a large existing codebase is huge.

At this point moving to Qt for something as large as Inkscape would be too massive I imagine. Just +1'ing your point.

Inkscape's UI uses so much common elements out of GTK too that it would really hose some of the developed creature comforts the community has got used to. It'd be a huge project with not a lot of ROI to go and redo all the chrome.

Sure, but how does it compare with gtk 2 vs 3? We're already talking about replacing a working toolkit with a significantly different one.

> Qt is an easy sell on fresh projects, but switching a large existing codebase is huge.

There have been a lot of major projects ported to Qt over the years, both commercial and open source (e.g. Wireshark, Subsurface).

I'm well aware. We've also sent spacecraft to Mars. Porting a large codebase from one UI toolkit to another, all the while giving up hard-earned knowledge in a volunteer-driven project is still a super daunting task.

I'd argue that this depends a lot how the code is structured. Back in the day of Win32 and MFC it was not unusual at all to very tightly integrate logic and the UI, often even outsourcing parts of state machines to GUI controls etc.; such a code base is difficult to port to anything. If, on the other hand, the application is written in a more layered approach, then porting from one toolkit to another may mean to just re-engineer the UI and only the UI. Complex custom controls mentioned by Raphael below are another factor.

It's a graphic design program. If there is a project where tight integration between the graphic library and the rest of the codebase is expected (for performance reasons) and hard to avoid is here.

In wireshark, for example, its meat is in the networking code, and the important skills of the developers are there, on inkscape, on the other side, the non-trivial contributions probably happen very near to the graphic frontend. If GTK goes to the gutter, retraining the developers to get to the same level in Qt will set Inkscape back years.

I'd argue that both WireShark and Subsurface have much simpler UI (and use mostly standard widgets) than Inkscape.

If Wireshark is any example, definitely not. I've not met anyone that likes the Qt version (in VoIP, it's an indispensable tool used all the time) - it seems like it lost a ton of polish.

This is somewhat off-topic, but I'm curious since every person who has had this sentiment that I've known was unable to provide specific parts which were lacking. Do you perhaps have a short list of top things which are missing their polish with the Qt version of Wireshark?

I'm just a light user of the tool and am genuinely curious about what things it may have lost in the transition.

I’m I using it for debugging barcode scanners talking to a web service. I much prefer the qt based UI. It’s much faster and obviously feels much more native to the platform

> more native to the platform

For a specific platform, or multiple?

The Qt version is miles ahead on OSX since it's no longer a clunky X11 app.

Qt works much better than GTK+ on both Windows and macOS. Unlike GTK+, it’s much harder to distinguish a Qt app and a native app for those platforms.

Cue the downvotes, but at least if you use Electron and build a custom UI you don't need to worry about it being unsupported or poorly supported in the future on certain platforms. It's just HTML + CSS which is going to be around a lot longer than the current iteration of UI frameworks.

(Ok yes, you could still face issues with the underlying runtime being unsupported, but I have a feeling that and JavaScript are going to stick around for a while)

>Cue the downvotes, but at least if you use Electron and build a custom UI you don't need to worry about it being unsupported or poorly supported in the future on certain platforms.

Yes, you'll don't have to worry: you'll be certain that it is poorly supported today and in the future on all platforms as far as the topics we discuss are concerned (native UI likeness).

I'll take a non-native looking app that works (every Electron app I've tried on macOS) over XQuartz-based garbage that hangs forever at startup, as the current "stable" Inkscape release does for me.

Maybe, but not for a graphics editor.

Slack hogs RAM and burns battery like crazy, and it's a bloody chat app -- as simple as it gets.

Now imagine an Electron version of Inscape with complex vector editing, gradients and co on screen...

It's not even very hard to imagine. Just go to any web-based diagram drawing service (there's plenty of that), and look how sluggish and crappy it feels even when performing simplest and most basic tasks. Now multiply that crappiness 10x for the complexity of vector drawings (100x if you're doing vector art), and additional 10x for the complexity of the effects vector formats can handle - and you'll get a ballpark of how Inkscape would feel if it was an Electron app.

I've used https://app.moqups.com/ for diagramming/wireframing for a few years, and it doesn't feel sluggish to me at all. Feel pretty snappy, in fact.

We don't have to imagine. Someone has made a clone of Sketch for the web: https://app.designer.io/. There's an app to download as well.

It doesn't match the performance of a native equivalent, but doesn't seem unreasonably slow or bloated either.

There are also two other Electron-based vector graphics editors on the app store:

- Boxy SVG - https://itunes.apple.com/us/app/boxy-svg/id611658502

- Vectr - https://itunes.apple.com/us/app/vectr/id1204645754

Can we tell without feature parity? I were writing such a webapp, I'd skip features that were slow.

The OP suggested that no web/Electron based editor could have "complex vector editing, gradients and co on screen". This has nothing to do with achieving 100% feature parity, so yes, we can tell. Anything else is moving the goalposts.

100% feature parity is a meaningless test in any case. Sketch doesn't have 100% parity with Inkscape, which doesn't have 100% parity with Affinity Designer, which doesn't have 100% parity with Illustrator, etc.

Boxy SVG [1] is an Inkscape clone built with Electron and Xel widget toolkit [2]. I would say its UI is on pair with native macOS apps such as Pages or Keynote.

[1] https://itunes.apple.com/us/app/boxy-svg/id611658502

[2] https://xel-toolkit.org/

I think the downvotes are partly because of your "Cue the downvotes" at the beginning... beyond this, even as a big fan of Electron based applications, for a lot of things, it's not a great fit for a many things. I'm not sure a vector graphics program is a good fit or not, or where the edges in performance may be. I know that using it for heavy filters on raster art would be too slow comparatively for many.

Frankly, VS Code is probably the only moderately complex application that really shows off Electron. Many electron apps just aren't that well written, and not to besmirch any developers working in other toolkits, making good JS code in a larger codebase is a different kind of skill than most are used to, beyond this, the techniques and approaches for performance gains are also fairly different.

I don't think Chrome, JS, Node or Electron are going anywhere any time soon. There are some definite value wins in that space. That doesn't make it a great fit here, but I'm happy to be surprised.

My experience with many years of pushing Illustrator's limits is that the big performance hits are:

1. lots of transparency with the GPU acceleration on - it very quickly becomes an order of magnitude slower than the CPU renderer, especially if you do tricks to generate 3-4 translucent shapes from every path you draw by hand like I do nowadays 2. adding new objects to a complex file starts getting super slow (somewhere around 4-5000 paths, less if you're generating lots of virtual paths via various effects) - I'm not sure if this is due to running out of physical memory, or trying to insert new items. in the middle of a very large and complex list of items, or what 3. a few large bitmap effects at 300dpi can very quickly bring IllustratorI to its knees, I'm not sure if this is due to using up tons of memory, unoptimized image convolution routines, or simply having to grovel through a lot of data. 4. also you can do some really terrible things to Illustrator's performance very quickly by applying a distortion mesh to a shape with a pattern fill that contains a lot of copies of its pattern 5. in general there's a lot of ways to send performance over a cliff by making the program generate a hell of a lot of shapes from simple rules - scatter brushes deposit a lot of copies of a shape along the path you draw, art brushes distort a shape along your drawn path, you can generate multiple paths with various programmatic effects applied to them from a single path...

You could probably edit moderately complex files with a theoretical vector package working under the handicap of being interpreted JS running in a neutered web browser. I did nice stuff with Illustrator way back in 2000, on machines that ran slower than a modern box would after the additional overhead of running compiled JS in a neutered web browser. But I sure wouldn't consider it for high-end work.

I agree... I only meant that there are differences, and the style of programming it takes for high performance JS is sometimes counter intuitive to what one would do in another language. The browser is effectively a sandboxed operating system at this point... there's a LOT you can do there.

For that matter, I'm a pretty big fan of the chromebook model, so all the more happy to see web based apps working, even if google seems to be taking a couple steps back in that space. I'm simply unsure if the time/effort it would take, combined with the differing skills combined would yeild something better... more portable maybe, but not necessarily better.

Who knows though.

> if you use Electron and build a custom UI you don't need to worry about it being unsupported or poorly supported in the future on certain platforms. It's just HTML + CSS which is going to be around a lot longer than the current iteration of UI frameworks.

No, you just have to worry about JS frameworks that change every week, and HTML/CSS support which also tends not to be very stable over time. Forget about pixel-perfect UIs.

Also, the way people write those pseudo-desktop apps, their UI breaks in really funny ways when your Internet connection lags. This is not Electron issue per se, but the issue of culture around web tools.

I've been very pleased with Inkscape for general draw program use. I use it to create Wikipedia illustrations, since Wikipedia prefers SVG.

For simple vector diagrams, I've found https://www.draw.io (similar to MS Visio) to be very convenient. The code is also open source (Apache-2.0): https://github.com/jgraph/draw.io

I didn't know about draw.io's license - that is great. I have been enjoying yEd but also looking for other diagramming software since rotating text is difficult in yEd, and it's not free software [2].

[1] https://www.yworks.com/products/yed

[2] http://yed.yworks.com/support/qa/515/why-not-an-open-source-...

I agree that Inkscape is awesome, but the UI still could use some love in some places. What I am regularly missing, for example, is a widget that displays nested groups as intuitively as Adobe Illustrator does.

Inkscape gives you a possibility to search for elements with its XML-widget, but that one is really fiddly and doesn't support many really useful usecases (quickly toggling visibility, selecting multiple elements, regrouping by dragging elements out of a group...).

Like the objects dialog in 0.92 ?

Oh, did I miss out on something? ...I'll have a look at that then, thanks for the hint! :-)

I found the same issue, so promptly moved to use BoxySVG, which I must say is pretty amazingly simple and modern.

Sure, it's not open source, but it is free.

When I was using OS X, I used to compile my own version using Brew that behaved like a native application.

There are flags to do just that, but it's a very lengthy process, because you have to compile GTK and other libraries first.

It works well, although there are occasional bugs, such as the shortcut keys using Ctrl instead of Cmd, if I recall correctly.

You know, I'd be willing to do that. Do you know of a good tutorial on this?

No need to compile GTK, etc. yourself. Homebrew has you covered.

    brew tap caskformula/caskformula
    brew install caskformula/caskformula/inkscape

Mentioned at the bottom of the page [1].

[1]: https://inkscape.org/en/download/mac-os/

You've just explained why you find it intuitive / better... (familiarity). Inkscape/Illustrator/whatever doesn't really have a layout, it's just: shit all over the place, some in tool palette thingimombobs, some hidden under contextual menus and file menus. Sometimes there is some effort to make mode based or hierarchy give some kind of sense of order but it's always artificial, there are too many tools and there don't need to be.

I know you have to learn to love these things when you use them daily, and you can isolate yourself from the most offensive bits through gradual configuration... but when you step back and be objective, cmon, it's a steaming pile o' crap.

Oh yeah, and moving to gitlab isn't going to help that.

Save yourself the hassle and buy Affinity Designer – it does a better job of most of what I did before with Adobe Photoshop & Illustrator (or Sketch for that matter).

I'm very grateful to my designer friend who recommended it to me.

It's 50 Euros... just buy it and get happy :)

It works okay-ish for me, although I pretty much never use copy&paste in XQuartz on mac. But I still can't name a better free vector graphics program on mac.

Me too. Not a great issue, though the XQuartz background thing kinda screws up Command+tab, it's still perfectly usable, if a little rough around the edges.

GIMP works decently well under OSX. It didn't until recently, though; it used to be the same XQuartz story until they finished the native GTK+ build.