Hacker News Reader

Comment by clumsysmurf | Hacker News Reader

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.

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?

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.

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

> 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.

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.

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.

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

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.

Reply on news.ycombinator.com