7 ms·

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

scrollaway 9y ago
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.
- kraig911 9y ago
  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.
  - yjftsjthsd-h 9y ago
    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.
- MichaelGG 9y ago
  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.
  - Etzos 9y ago
    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.
  - pilif 9y ago
    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
    - yjftsjthsd-h 9y ago
      > more native to the platform For a specific platform, or multiple?
      - Kwpolska 9y ago
        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.
      - inferiorhuman 9y ago
        The Qt version is miles ahead on OSX since it's no longer a clunky X11 app.
- dom0 9y ago
  > 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).
  - scrollaway 9y ago
    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.
    - dom0 9y ago
      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.
      - Thimothy 9y ago
        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.
  - raphman 9y ago
    I'd argue that both WireShark and Subsurface have much simpler UI (and use mostly standard widgets) than Inkscape.
lucaspiller 9y ago
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)
- coldtea 9y ago
  >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).
  - stupidcar 9y ago
    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.
    - coldtea 9y ago
      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...
      - TeMPOraL 9y ago
        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.

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.

kraig911 9y ago
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.
- yjftsjthsd-h 9y ago
  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.
MichaelGG 9y ago
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.
- Etzos 9y ago
  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.
- pilif 9y ago
  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
  - yjftsjthsd-h 9y ago
    > more native to the platform For a specific platform, or multiple?
    - Kwpolska 9y ago
      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.
    - inferiorhuman 9y ago
      The Qt version is miles ahead on OSX since it's no longer a clunky X11 app.
dom0 9y ago
> 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).
- scrollaway 9y ago
  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.
  - dom0 9y ago
    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.
    - Thimothy 9y ago
      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.
- raphman 9y ago
  I'd argue that both WireShark and Subsurface have much simpler UI (and use mostly standard widgets) than Inkscape.

lucaspiller 9y ago

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)

coldtea 9y ago
>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).
- stupidcar 9y ago
  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.
  - coldtea 9y ago
    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...
    - TeMPOraL 9y ago
      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.