Hacker News Reader

Comment by scrollaway | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com