5 ms·

After over a decade of using a Gtk-based desktop, I have finally given up on Gtk. A few of the most memorable things that have driven me away: Client-side wind

After over a decade of using a Gtk-based desktop, I have finally given up on Gtk. A few of the most memorable things that have driven me away: Client-side window decorations: ugh. I miss being able to see at a glance which window has input focus, even if some of them are partially covered. I miss having consistent grab areas for all windows. I miss being able to click or drag any part of the title bar without having to avoid whatever widgets some clever app developer decided to shove into that space. I miss consistent keyboard and mouse controls for rearranging windows, configurable in one place. I miss small title bars. I miss window frames that draw correctly without a compositor. A theme engine that ensures all themes are broken: Gtk complains whenever the desktop theme contains something that is out of spec, and seems to change the spec with every minor version. The result: Unless you only use the officially blessed and version-matched theme that comes with your version of Gtk, it constantly belches warning messages into ~/.xsession-errors, needlessly increasing wear on the SSD, and making it a pain to wade through all the Gtk spam if you ever have to use that log file to troubleshoot a real problem. Why even have a theming engine if no theme can ever hope to work properly for more than a month or two? System tray icons: These are very useful to me, all day, every day of my life. Gtk is removing them. Various third party libraries have appeared in attempt to restore the missing functionality, but since they're not native parts of the toolkit, I doubt that any of them will ever work quite as well or become a clear choice for app developers. A mess of an API: It looked reasonable enough at first glance, but in my (admittedly limited) experience coding with Gtk, I found that most of my time was spent troubleshooting different interfaces for the same task, having to discover by trial-and-error which ones were broken in which ways, and moving on to the next, until finally settling on one that did the job with the fewest problems. Perhaps some of those were old and deprecated, but I was unable to find documentation to that effect, nor any guidance on which bits were considered current or how to manage their quirks. I felt like the toolkit was constantly fighting me, wasting my time. It seems I'm not the only one who had trouble here: https://www.phoronix.com/scan.php?page=news_item&px=MTU2ODM https://www.phoronix.com/scan.php?page=news_item&px=MTU2ODM None of this is news. Gtk has been inflicting bad design decisions on users for years now, but since changing ecosystems (both as a user and as a developer) is a time-consuming chore, I have been quietly hoping that it would get better. Instead, it has consistently been getting worse. I'll miss my trusty old classic Xfce, but I'm done.

Rochus 5y ago
That was helpful, thanks. What do you use instead of GTK?
- foresto 5y ago
  Qt looks like the strongest candidate right now. I haven't started coding with it yet, so I don't know whether I'll embrace KML in my own code or go a more traditional route. One thing that stands out as a potential limitation: Between C++ and the metaobject compiler, I have the impression that higher level language bindings for Qt are more difficult to create (and therefore more scarce) than bindings for C-based toolkits. The Python bindings seem widely used, so that's nice, but I don't know about Nim (which recently piqued my curiosity) or Rust (which is getting popular). I would rather not go back to C++; I used it a lot in the past, but it was never fun or respectful of my time. On the desktop side, I'm leaning toward KDE. It was too heavyweight for me when I tried it ages ago, but recent Plasma releases seem to have lightened up quite a bit, and allow me to strip out much of the eye candy in favor of a more utilitarian experience. (It's still not what I would call lightweight, but it's closer than it was, and alternatives have been gaining bloat and closing the gap anyway.) LXQt seemed rough when I last checked, but if it ends up developing into something as nice as Xfce used to be, I'll definitely give it another try. I also intend to keep looking out for new cross-platform GUI toolkits. I have noticed a few in recent years, mostly in the mobile space, but whether they will mature into well-designed cross-platform kits that cover most people's needs remains to be seen. It's not an easy task.
  - Rochus 5y ago
    > I would rather not go back to C++; I used it a lot in the past, but it was never fun or respectful of my time. I think Qt and C++ is a very powerful combination; Qt core essentially covers every aspect of the C++ standard libraries so I no longer use the latter; even before C++11 Qt had good solutions to avoid copies of data structures, and to implement efficient callbacks and systematic memory management, and tbh I still use very little of the more recent C++ features; it's also possible to build very fancy looking GUIs using the Qt stylesheets or QGraphics classes if need be. And nearly all code I write runs automatically on all platforms supported by Qt; I even use Qt core on Linux based embedded systems; asynchronous services were supported long before the JS folks got a taste for it. KDE undoubtedly offers some interesting features, but slimness and platform independence are much more important to me. > but whether they will mature into well-designed cross-platform kits that cover most people's needs remains to be seen. It's not an easy task I think the mobile use case is too different from the desktop one to provide decent support for both in a single framework. From my point of view Qt (besides Qt core) is only of limited use on mobile platforms, and frameworks like Flutter are (up to now) only of limited use on desktops. Even if the framework would support both in a decent way, the GUI for desktop and mobile must be designed quite differently to be used efficiently; platform-independent GUI code is therefore of little use here.

Rochus 5y ago

That was helpful, thanks. What do you use instead of GTK?

foresto 5y ago
Qt looks like the strongest candidate right now. I haven't started coding with it yet, so I don't know whether I'll embrace KML in my own code or go a more traditional route. One thing that stands out as a potential limitation: Between C++ and the metaobject compiler, I have the impression that higher level language bindings for Qt are more difficult to create (and therefore more scarce) than bindings for C-based toolkits. The Python bindings seem widely used, so that's nice, but I don't know about Nim (which recently piqued my curiosity) or Rust (which is getting popular). I would rather not go back to C++; I used it a lot in the past, but it was never fun or respectful of my time. On the desktop side, I'm leaning toward KDE. It was too heavyweight for me when I tried it ages ago, but recent Plasma releases seem to have lightened up quite a bit, and allow me to strip out much of the eye candy in favor of a more utilitarian experience. (It's still not what I would call lightweight, but it's closer than it was, and alternatives have been gaining bloat and closing the gap anyway.) LXQt seemed rough when I last checked, but if it ends up developing into something as nice as Xfce used to be, I'll definitely give it another try. I also intend to keep looking out for new cross-platform GUI toolkits. I have noticed a few in recent years, mostly in the mobile space, but whether they will mature into well-designed cross-platform kits that cover most people's needs remains to be seen. It's not an easy task.
- Rochus 5y ago
  > I would rather not go back to C++; I used it a lot in the past, but it was never fun or respectful of my time. I think Qt and C++ is a very powerful combination; Qt core essentially covers every aspect of the C++ standard libraries so I no longer use the latter; even before C++11 Qt had good solutions to avoid copies of data structures, and to implement efficient callbacks and systematic memory management, and tbh I still use very little of the more recent C++ features; it's also possible to build very fancy looking GUIs using the Qt stylesheets or QGraphics classes if need be. And nearly all code I write runs automatically on all platforms supported by Qt; I even use Qt core on Linux based embedded systems; asynchronous services were supported long before the JS folks got a taste for it. KDE undoubtedly offers some interesting features, but slimness and platform independence are much more important to me. > but whether they will mature into well-designed cross-platform kits that cover most people's needs remains to be seen. It's not an easy task I think the mobile use case is too different from the desktop one to provide decent support for both in a single framework. From my point of view Qt (besides Qt core) is only of limited use on mobile platforms, and frameworks like Flutter are (up to now) only of limited use on desktops. Even if the framework would support both in a decent way, the GUI for desktop and mobile must be designed quite differently to be used efficiently; platform-independent GUI code is therefore of little use here.