6 ms·

> [...] GTK is perfectly fine for Linux. This is great news, so now it is the best time to make thin wrappers around these stable things so that we can all go m

> [...] GTK is perfectly fine for Linux. This is great news, so now it is the best time to make thin wrappers around these stable things so that we can all go make useful software.. Hoping not to start any kind of framework quarrel, but my understanding was that quite many applications (such as Wireshark, Subsurface, and OpenShot) are moving from GTK to Qt very much due to Qt being more stable. Or is the main reason cross-platform compatibility?

blub 10y ago
Qt is better supported and easier to use compared to GTK. It's also probably the best cross-platform toolkit one can get right now. Was surprised to hear that even Linus got sick of dealing with GTK and ported Subsurface to Qt, but that's how it is.
- audidude 10y ago
  Contrary to what people seem to think, just because GTK+ compiles on Windows and OSX, doesn't mean we are trying to be a cross-platform toolkit. Many GTK+ developers consider GTK+ to be a platform in it's own right, not a portability layer.
  - Koromix 10y ago
    I understand this, even though the constant breaking of GTK apps after each update annoys me to no end. But you might want to discuss updating https://www.gtk.org/ https://www.gtk.org/ and other sites for that matter. Quoting the first lines of the home page: "GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces".
    - audidude 10y ago
      If your platform is X11, Wayland, or Mir :)
      - Koromix 10y ago
        And then you go to the Features page, with a box on the right clearly listing "GNU/Linux and Unix / Windows / Mac OS X" as supported plartforms :) With "Native look and feel" in the box just below. I disagree with the current GTK direction, but it's not my project and I accept that. If the focus of the project has changed, update the website(s) and documentation. Also the HTTPS stuff pointed out by distances.
        audidude 10y ago
        Agreed. It seems wildly out of date. I'll track down who has access to the site and see if we can update it during the hackfest in a couple weeks.
        andlabs 10y ago
        Benjamin Otte recently added uxtheme.dll support to the CSS engine and I've already seen a few screenshots of the win32 theme using it to okay effect. I wrote a patch to add OS X cursor support to GDK last year and it was taken, not to mention work by Christian Hergert and others to improve the relatively new GDK/Quartz backend. So I'm pretty sure Windows and OS X are supported platforms :)
        deleted 10y ago
        [deleted]
    - distances 10y ago
      Just a side note in case some representative happens to be around, the https link above delivers an invalid certificate.
      - thwarted 10y ago
        And no content. I get a web server directory listing, with no entries. The content only seems to be served via http.
- mikeokner 10y ago
  I'm pretty sure the QT migration occurred after Linus stopped maintaining the project and handed the reins to Dirk Hohndel.
- wander_homer 10y ago
  Linus didn't port Subsurface to Qt, other people who were already experienced with Qt did. If you have a look at their talk at linux.conf.au it's pretty obvious that they had no idea what they were doing when they wrote the GTK+ interface. I mean they weren't able to do a proper star rating widget in GTK+ and blame GTK+ for that. But doing that with Qt is just the same amount of work and they didn't even write that themselves, but the one responsible for the Qt port did. So what they are actually complaining about is: There was no one with a basic understanding of GTK+ who wrote the interface for us. Yes, GTK+ has lots of quirks and I curse it on a regular basis, but so do Qt and all other toolkits I know of. And yes using Qt for Subsurface instead of GTK+ was a good idea, since Windows and OS X ports benefit a lot from that, but if Dirk and Linus were responsible for the Qt interface, it probably would have been just as bad as the GTK+ one.
jventura 10y ago
Personally, I prefer programming in Qt versus GTK. Also, I think GTK is losing developer's mind-share and Qt is moving forward faster, is targeting mobile platforms, is quite active, backed by a company, etc., etc. This kind of things are very important because some of us would like to make a living out of these things! As someone who would like to create a commercial application for desktop, I really appreciate that at least the UI frameworks for Windows and OSX are quite stable.
Zardoz84 10y ago
Qt simply works better. I saw GTK showing many artifact and/or working at glacial speed when buggy drivers or SVGA driver (not 2D acceleration) are in. However Qt works flawless on the same situation, even with some nice FX working.
- audidude 10y ago
  Have a bug number? Link to the driver issues? I've worked on a lot of systems, including popular virtual machines display implementations (the most likely system to hit the SVGA mode) and have not seen this. I have, however, seen compositors that hit buggy mesa llvmpipe paths corrupt the visual output on the way to the GPU. But that would have happened to Qt as well unless you ran the Qt app on a non-composited desktop (which wouldn't really be an apples-to-apples comparison).
random443 10y ago
My personal reason is that GTK 3+ lost his track in what constitutes a desktop widget set. It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. So if the non-technical users are actually migrating to dumb web-apps and couldn't care less, the technical crowd which demand power features and efficiency are getting fed up. As a developer, I certainly am. The trend started already with the latest 2.x series in GTK, not with GTK 3. My standards for quality on the desktop are way higher than what the "web" is supposed to give you today. It must be fast, consistent, and don't have any glitch. The looks are a secondary point (and GTK 2 engines, or Qt4 for the matter) already give you great customization possibilities, which are way beyond what most other systems can do already. GTK 3 and QML (Qt5) would like to target the same space as web applications. It doesn't make sense. Applications which are written with a web UI in mind will translate very poorly on the desktop, and the opposite is also true. My experience with QML was abysmal, and definitely not worth the extra dependency. Maybe you think that you button must be big and fat and have extra space to be tapped on-to, but on a desktop this is all wasted space on the screen that I want to use for data. GTK 3 is trying to innovate a bit on the UI front, but many of the changes come with usability regressions on the desktop which I don't find acceptable anymore. Overlay scrollbars are a good example. In principle, they're a great idea. However the implementation is riddled of bugs which makes using scrollbars with a mouse a pain. The CSS theming is nice, but they keep breaking the styles at each minor release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering in a GL context, the reality is that if you want predictable performance they're going to be useless anyway.
- audidude 10y ago
  > It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. This is simply not true. We are closer to hitting 60 fps (or whatever your EDID actually presents) than ever before, and staying locked to that. The more complex of an interface you create, the harder that is, but that is no different today than ever before. Work is underway doing something similar to the webrender concepts which will improve render times even further. I'm not sure what you mean by visual consistency, other than we create new widgets as designers ask for them. Just because applications choose to use something other than say a GtkComboBox for everything is hardly our fault. I welcome a future where application developers can decide what UI concepts work for them. That doesn't mean you can't use deprecated widgets. This is no different than any other platform. We experiment with new ideas, keep what works well, and deprecate what doesn't based on feedback and user testing. GTK+ is one of the few libraries that generally stays ABI stable for a decade, so deprecated is more of an indicator than "this will be removed next month" like developers are used to with web APIs. > GTK 3 and QML (Qt5) would like to target the same space as web applications. It doesn't make sense. Applications which are written with a web UI in mind will translate very poorly on the desktop, and the opposite is also true. My experience with QML was abysmal, and definitely not worth the extra dependency. Maybe you think that you button must be big and fat and have extra space to be tapped on-to, but on a desktop this is all wasted space on the screen that I want to use for data. Where do you get your information? Because they seem to be fairly miss-informed. GTK+ is most definitely not trying to be a web application toolkit. The "big buttons" are that size because people have all sorts of accessibility needs different from your own. Or you're on HiDPI and we don't have 1.5x scaling (yet) as it requires more plumbing in the compositor to do 3x scaling in the toolkit and 2x downscaling (and input transformations) in the compositor. I hope to see this before long. Personally, I'd like to see a "condensed" theme variant of sorts. Finally, thanks to all the CSS node work in 3.20, you can pretty much get that with a couple CSS lines. > The CSS theming is nice, but they keep breaking the styles at each minor release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering in a GL context, the reality is that if you want predictable performance they're going to be useless anyway. It's no secret to GTK+ developers that the theming API was always sort of a gray area. As of 3.20 the theming API, for the first time in nearly 18 years, is considered stable. GTK+ does not render with GL today. (There is integration to embed GL into the scene, though). That might land for 3.22, but it's a lot of work and I would not be surprised if it doesn't make it until 3.24 as it's part of the drain-the-swap redesign of the drawing model. Presumably vulkan will be supported too.
dguaraglia 10y ago
GTK has the advantage of being a C library with not that many dependencies (so, simple to wrap.) QT (at least in my very limited experience) has way more dependencies, some weird build steps (MOC anyone?) and writing stubs for it would require much more code. That said, I haven't programmed a UI in about 5 years, so this might be completely outdated.

blub 10y ago

Qt is better supported and easier to use compared to GTK. It's also probably the best cross-platform toolkit one can get right now. Was surprised to hear that even Linus got sick of dealing with GTK and ported Subsurface to Qt, but that's how it is.

audidude 10y ago
Contrary to what people seem to think, just because GTK+ compiles on Windows and OSX, doesn't mean we are trying to be a cross-platform toolkit. Many GTK+ developers consider GTK+ to be a platform in it's own right, not a portability layer.
- Koromix 10y ago
  I understand this, even though the constant breaking of GTK apps after each update annoys me to no end. But you might want to discuss updating https://www.gtk.org/ https://www.gtk.org/ and other sites for that matter. Quoting the first lines of the home page: "GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces".
  - audidude 10y ago
    If your platform is X11, Wayland, or Mir :)
    - Koromix 10y ago
      And then you go to the Features page, with a box on the right clearly listing "GNU/Linux and Unix / Windows / Mac OS X" as supported plartforms :) With "Native look and feel" in the box just below. I disagree with the current GTK direction, but it's not my project and I accept that. If the focus of the project has changed, update the website(s) and documentation. Also the HTTPS stuff pointed out by distances.
      - audidude 10y ago
        Agreed. It seems wildly out of date. I'll track down who has access to the site and see if we can update it during the hackfest in a couple weeks.
        andlabs 10y ago
        Benjamin Otte recently added uxtheme.dll support to the CSS engine and I've already seen a few screenshots of the win32 theme using it to okay effect. I wrote a patch to add OS X cursor support to GDK last year and it was taken, not to mention work by Christian Hergert and others to improve the relatively new GDK/Quartz backend. So I'm pretty sure Windows and OS X are supported platforms :)
        deleted 10y ago
        [deleted]
  - distances 10y ago
    Just a side note in case some representative happens to be around, the https link above delivers an invalid certificate.
    - thwarted 10y ago
      And no content. I get a web server directory listing, with no entries. The content only seems to be served via http.
mikeokner 10y ago
I'm pretty sure the QT migration occurred after Linus stopped maintaining the project and handed the reins to Dirk Hohndel.
wander_homer 10y ago
Linus didn't port Subsurface to Qt, other people who were already experienced with Qt did. If you have a look at their talk at linux.conf.au it's pretty obvious that they had no idea what they were doing when they wrote the GTK+ interface. I mean they weren't able to do a proper star rating widget in GTK+ and blame GTK+ for that. But doing that with Qt is just the same amount of work and they didn't even write that themselves, but the one responsible for the Qt port did. So what they are actually complaining about is: There was no one with a basic understanding of GTK+ who wrote the interface for us. Yes, GTK+ has lots of quirks and I curse it on a regular basis, but so do Qt and all other toolkits I know of. And yes using Qt for Subsurface instead of GTK+ was a good idea, since Windows and OS X ports benefit a lot from that, but if Dirk and Linus were responsible for the Qt interface, it probably would have been just as bad as the GTK+ one.

jventura 10y ago

Personally, I prefer programming in Qt versus GTK. Also, I think GTK is losing developer's mind-share and Qt is moving forward faster, is targeting mobile platforms, is quite active, backed by a company, etc., etc. This kind of things are very important because some of us would like to make a living out of these things! As someone who would like to create a commercial application for desktop, I really appreciate that at least the UI frameworks for Windows and OSX are quite stable.

Zardoz84 10y ago

Qt simply works better. I saw GTK showing many artifact and/or working at glacial speed when buggy drivers or SVGA driver (not 2D acceleration) are in. However Qt works flawless on the same situation, even with some nice FX working.

audidude 10y ago
Have a bug number? Link to the driver issues? I've worked on a lot of systems, including popular virtual machines display implementations (the most likely system to hit the SVGA mode) and have not seen this. I have, however, seen compositors that hit buggy mesa llvmpipe paths corrupt the visual output on the way to the GPU. But that would have happened to Qt as well unless you ran the Qt app on a non-composited desktop (which wouldn't really be an apples-to-apples comparison).

random443 10y ago

My personal reason is that GTK 3+ lost his track in what constitutes a desktop widget set. It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. So if the non-technical users are actually migrating to dumb web-apps and couldn't care less, the technical crowd which demand power features and efficiency are getting fed up. As a developer, I certainly am. The trend started already with the latest 2.x series in GTK, not with GTK 3. My standards for quality on the desktop are way higher than what the "web" is supposed to give you today. It must be fast, consistent, and don't have any glitch. The looks are a secondary point (and GTK 2 engines, or Qt4 for the matter) already give you great customization possibilities, which are way beyond what most other systems can do already. GTK 3 and QML (Qt5) would like to target the same space as web applications. It doesn't make sense. Applications which are written with a web UI in mind will translate very poorly on the desktop, and the opposite is also true. My experience with QML was abysmal, and definitely not worth the extra dependency. Maybe you think that you button must be big and fat and have extra space to be tapped on-to, but on a desktop this is all wasted space on the screen that I want to use for data. GTK 3 is trying to innovate a bit on the UI front, but many of the changes come with usability regressions on the desktop which I don't find acceptable anymore. Overlay scrollbars are a good example. In principle, they're a great idea. However the implementation is riddled of bugs which makes using scrollbars with a mouse a pain. The CSS theming is nice, but they keep breaking the styles at each minor release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering in a GL context, the reality is that if you want predictable performance they're going to be useless anyway.

audidude 10y ago
> It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. This is simply not true. We are closer to hitting 60 fps (or whatever your EDID actually presents) than ever before, and staying locked to that. The more complex of an interface you create, the harder that is, but that is no different today than ever before. Work is underway doing something similar to the webrender concepts which will improve render times even further. I'm not sure what you mean by visual consistency, other than we create new widgets as designers ask for them. Just because applications choose to use something other than say a GtkComboBox for everything is hardly our fault. I welcome a future where application developers can decide what UI concepts work for them. That doesn't mean you can't use deprecated widgets. This is no different than any other platform. We experiment with new ideas, keep what works well, and deprecate what doesn't based on feedback and user testing. GTK+ is one of the few libraries that generally stays ABI stable for a decade, so deprecated is more of an indicator than "this will be removed next month" like developers are used to with web APIs. > GTK 3 and QML (Qt5) would like to target the same space as web applications. It doesn't make sense. Applications which are written with a web UI in mind will translate very poorly on the desktop, and the opposite is also true. My experience with QML was abysmal, and definitely not worth the extra dependency. Maybe you think that you button must be big and fat and have extra space to be tapped on-to, but on a desktop this is all wasted space on the screen that I want to use for data. Where do you get your information? Because they seem to be fairly miss-informed. GTK+ is most definitely not trying to be a web application toolkit. The "big buttons" are that size because people have all sorts of accessibility needs different from your own. Or you're on HiDPI and we don't have 1.5x scaling (yet) as it requires more plumbing in the compositor to do 3x scaling in the toolkit and 2x downscaling (and input transformations) in the compositor. I hope to see this before long. Personally, I'd like to see a "condensed" theme variant of sorts. Finally, thanks to all the CSS node work in 3.20, you can pretty much get that with a couple CSS lines. > The CSS theming is nice, but they keep breaking the styles at each minor release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering in a GL context, the reality is that if you want predictable performance they're going to be useless anyway. It's no secret to GTK+ developers that the theming API was always sort of a gray area. As of 3.20 the theming API, for the first time in nearly 18 years, is considered stable. GTK+ does not render with GL today. (There is integration to embed GL into the scene, though). That might land for 3.22, but it's a lot of work and I would not be surprised if it doesn't make it until 3.24 as it's part of the drain-the-swap redesign of the drawing model. Presumably vulkan will be supported too.

dguaraglia 10y ago

GTK has the advantage of being a C library with not that many dependencies (so, simple to wrap.) QT (at least in my very limited experience) has way more dependencies, some weird build steps (MOC anyone?) and writing stubs for it would require much more code. That said, I haven't programmed a UI in about 5 years, so this might be completely outdated.