6 ms·

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 co

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.
- twotavol 10y ago
  > The "big buttons" are that size because people have all sorts of accessibility needs different from your own What accessibility needs are you targeting when you make the buttons and titlebars bigger? Why did this change drop suddenly? Was there a cry from the majority of your users that the widgets are too small to use with desktop inputs? Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired?
  - audidude 10y ago
    > Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired? There are way more types of impairments than visually impaired. We do have high contrast themes to help with a subset of visual impairment. (Even visual impairment is a wide-spectrum). Many of us may not particularly like touch screens, but an incredible number of computers that run Linux/BSD these days have touch screens. Things should work out of the box for these computers whether or not you want one. So we can make arbitrary guesses at what the "majority" is but the reality is we have a lot of hardware that we should support. Getting real statistics about users in F/OSS is difficult due to the high overlap of people interested in personal privacy. So we try to make as informed of decisions as we can. Additionally, more computer users than you might image have various difficulties in using the computer. Even if its not a majority, say one in ten, is still a large number of users. Count yourself lucky that you don't have an impairment (right now). It is common that people have an impairment at some point in time (RSI, broken arm, etc). I certainly agree that HiDPI is often way too large today (again due to the need for compositor integration), and I also agree we should have a condensed mode. However, I'd probably argue to implement a condensed mode on top of an effective 1.5x scaling (3/2) rather than yet another option in the toolkit/themes.
    - 10y ago
twotavol 10y ago
>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. QML is not targeting the same space as web applications. Its a more flexible and dynamic way of creating user interfaces. Its designed so you can create UIs for kiosks, infotainment systems, mobile applications, games, and desktops all with one toolkit. QML has components specifically for desktop development that have the same look as your traditional forms based widgets.
microcolonel 10y ago
I'd like you to substantiate the claim that it "gets slower at each release" before I'll accept it, it conflicts with my experience. I've seen every single GNOME application get consistently faster for the last five releases; today (with GNOME 3.20) they render at ludicrous speed on even my oldest intel boxes.

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.

twotavol 10y ago
> The "big buttons" are that size because people have all sorts of accessibility needs different from your own What accessibility needs are you targeting when you make the buttons and titlebars bigger? Why did this change drop suddenly? Was there a cry from the majority of your users that the widgets are too small to use with desktop inputs? Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired?
- audidude 10y ago
  > Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired? There are way more types of impairments than visually impaired. We do have high contrast themes to help with a subset of visual impairment. (Even visual impairment is a wide-spectrum). Many of us may not particularly like touch screens, but an incredible number of computers that run Linux/BSD these days have touch screens. Things should work out of the box for these computers whether or not you want one. So we can make arbitrary guesses at what the "majority" is but the reality is we have a lot of hardware that we should support. Getting real statistics about users in F/OSS is difficult due to the high overlap of people interested in personal privacy. So we try to make as informed of decisions as we can. Additionally, more computer users than you might image have various difficulties in using the computer. Even if its not a majority, say one in ten, is still a large number of users. Count yourself lucky that you don't have an impairment (right now). It is common that people have an impairment at some point in time (RSI, broken arm, etc). I certainly agree that HiDPI is often way too large today (again due to the need for compositor integration), and I also agree we should have a condensed mode. However, I'd probably argue to implement a condensed mode on top of an effective 1.5x scaling (3/2) rather than yet another option in the toolkit/themes.
  - 10y ago

twotavol 10y ago

>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. QML is not targeting the same space as web applications. Its a more flexible and dynamic way of creating user interfaces. Its designed so you can create UIs for kiosks, infotainment systems, mobile applications, games, and desktops all with one toolkit. QML has components specifically for desktop development that have the same look as your traditional forms based widgets.

microcolonel 10y ago

I'd like you to substantiate the claim that it "gets slower at each release" before I'll accept it, it conflicts with my experience. I've seen every single GNOME application get consistently faster for the last five releases; today (with GNOME 3.20) they render at ludicrous speed on even my oldest intel boxes.