6 ms·

GTK3 is becoming very GNOME3 specific, while Qt5 is still agnostic and easy to port on different platforms.

cycloptic 7y ago
Can you elaborate? If you're talking about the client-side decorations in GTK, those are up to the app developer to choose if they want them or not.
- ori_b 7y ago
  As a user, I don't want them, and I don't want the app developer to make that choice for me.
  - arghwhat 7y ago
    The developers makes every decision on how an application works and looks (It's part of the code). The top row of pixels is no different.
    - infinity0 7y ago
      It feels like everyone someone voices an opinion about GTK3 explaining why they don't like it, some GTK3 fanboy has to chime in questioning the opinion and implying it isn't rational. Yeah, this makes me want to stick with GTK3 even less. People don't have to explain their preferences in a rational way, they will just switch away from GTK3. It's cheaper. Successful developers will try to interpret these users' feedback in a self-critical, introspective and positive way, and tweak their product based on the feedback. As opposed to continually challenging the giver of the feedback to explain their opinion in more detail, as if by repeatedly digging deeper and deeper into an opinion, you will at some point find some fundamental logical contradiction in their views that will make them re-evaluate their life philosophy on why they just don't like GTK3. I for one think the two opinions given above are perfectly clear ("GTK3 is becoming very GNOME3 specific", "As a user, I don't want them") and can't see why further clarification is being requested. If you really need clarification on these perfectly clear opinions, it is your problem.
      - arghwhat 7y ago
        No clarification at any point was necessary. Despite your rant here, I made no claims as to which was better, or whether a users opinion on that particular aspect was valid. Beauty is in the eye of the beholder, so one cannot claim right or wrong. What I stated was that development decisions, whatever they are, are up to the developers, including which frameworks they wish to use, and how they wish to use them. Saying in any form that you don't want developers to make decisions is nonsensical, as they would not be able to write anything then. Decisions have to be made, compromises chosen, and ultimately, not everyone will get their will. If you don't want other developers to make decisions for you, you're stuck writing all the software you want to use yourself.
        zapzupnz 7y ago
        > If you don't want other developers to make decisions for you, you're stuck writing all the software you want to use yourself. I suspect this of being as recent an attitude as "no, it's fine that a desktop chat client should take up nearly 4 GB doing absolutely nothing, memory is made to be used". There are enough of us who lived through the days when, no, developers didn't need to make certain decisions for us on the Linux desktop. It wasn't a perfect time but it did exist — as recently as ten years to fifteen years ago in the days of GTK+2 and KDE 3. Again, it wasn't perfect, but those days contradict your assertion. People shouldn't have their opinions discounted because they're no longer in vogue.
      - wruza 7y ago
        I agree. Asking for deep details is like asking “what’s wrong with you” instead of the reverse. Another show stopper for gtk is pretty trivial: it’s a real pain in the ass to get a working set of dlls on windows. The most sane way I know is to incrementally cut it from msys2 installation. That’s plain stupid and is killing an already half-dead framework, which was pretty good at the 2.x days. It locked itself into gnome, which is not even a crushing leader on linux desktops.
        cycloptic 7y ago
        I haven't tested it but I believe there is a "gtk" package in vcpkg that can be used. Windows support should still work fine, but improving the experience there has never really been a priority simply because of lack of developer interest. Unlike Qt, there is no company behind it, it's open source managed by a non-profit and anyone can work on it. Right now there are only ~2 developers contributing full-time and they work for Red Hat. So unless someone else wants to hire developers to work on it, that's who is calling the shots and they are going to focus on their platform. I also don't really appreciate being called a "fanboy" by the GP. I use Qt as well and I don't favor any framework over another. I'm sticking to the facts here: GTK supports building apps any way you want, not just in the GNOME style. Maybe the problem is that the apps you tried happen to all be GNOME-styled apps. That's a choice that the app developers have to make consciously and has nothing to do with GTK. If there is something else you mean by "locked into GNOME" then please elaborate, because I am having trouble understanding what you're referring to.
    - rixed 7y ago
      The developers of Qt applications do not force how the UI will look like. Users can customize it with local style sheets (usually from the desktop environment).
      - cycloptic 7y ago
        GTK also supports customization via local style sheets. In Qt it's absolutely possible for applications to force client-side decorations and force a certain stylesheet. Maybe it's not common in the apps you use, but again, it's up to the app developer if they want to make use of those things or not.
        dependenttypes 7y ago
        > GTK also supports customization via local style sheets. They also break them at every release.
        cycloptic 7y ago
        That's just plain FUD. The only release I remember breaking CSS was 3.20, and that was because all the CSS was refactored to allow for way more theming possibilities. Regardless of that I don't see anything based on "cascading styles" as lending itself to a stable theming system anyway. The CSS is probably going to change any time a widget is added/refactored/bugfixed, this holds true on the web as well once you build up a complex library of React components or whatever. The point of it is that there are multiple styles from multiple sources that can cascade together. It's powerful but it can result in a lot of complexity, anyone who's had to add !important directives can attest to that. It needs to be strictly managed by the developers to really work correctly and to prevent the style overrides from getting out of hand. Allowing custom user CSS is only for power users who understand the caveats.
      - arghwhat 7y ago
        You can do that under Gtk3 too, but like with Qt5 it only allows small adjustments in line with how the developers built the UI. You can affect layout and style of certain components, but that's it. From the perspective of making design decisions, it's somewhat equivalent to swapping the phone shell on a Nokia 3310.
    - ptx 7y ago
      What about the filesystem drivers? Should each application developer pick those? Applications run as part of a system that provides certain shared system-wide features and is configured by the user. They should slot into that system.
      - genpfault 7y ago
        > What about the filesystem drivers? Should each application developer pick those? KIO vs GVFS? :)
      - arghwhat 7y ago
        What shared services that are available differs from system to system, just like which are supported differ from applucation to application. Filesystem access may be through an xdg-portal, may support KIO or GVFS integrations, may use framework internal pickers, and so forth. Many decisions for the developers to make. Filesystem drivers are much further down the stack, but that's just a different group of developers making all the decisions.
  - cycloptic 7y ago
    A toolkit unfortunately can't enforce that. You have to ask the app developers to change their design.
    - ori_b 7y ago
      Sure it can. Until fairly recently, client side decorations were simply unsupported, and things worked better.
      - cycloptic 7y ago
        No, they were always supported in the sense that it has always been possible to make a frameless window and draw your own decorations. In the old days this was even a highly desired thing for Audacious/Beep/XMMS because of compatibility with Winamp skins, which all included their own graphics for window decorations. The only thing that has become supported in GTK fairly recently is a common appearance for them. If you notice more app developers happening to use them lately, that's a different issue driven by design trends, not by what some toolkit decides to support. Technically speaking, CSD is not exactly a new thing and has been the norm on Windows and Mac for quite a long time now. Design-wise, the practice of putting widgets into the title bar is what app developers are wanting now. Have you noticed the UI in the newest Chrome? Or iTunes? All the topmost widgets are moved up into the title bar. This is where we are headed at the moment.
        ori_b 7y ago
        It's been theoretically possible for a while, but hard to do, as well as being considered antisocial. It's quite a new regression on Mac as well.
        cycloptic 7y ago
        It was not hard to do, it's as trivial as drawing 2 buttons and some text. If this is such an issue then take it up with all the app developers. See for yourself how well they respond to accusations of being "antisocial" just for the act of moving some buttons up 30 pixels. This isn't a new thing or a regression on Mac, they always had CSD, even in the pre-OS X days. What is trendy there now is the merging of the toolbar and titlebar, which is different.
- guug 7y ago
  They deprecated functionality that no longer fit GNOME's workflow even if it is when it's still needed on other desktops and operating systems (see systray icons[1]). Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. Relying on GTK to be a cross-platform GUI toolkit is very risky given its current direction. [1]: https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html
  - cycloptic 7y ago
    I don't see how that follows and I think your explanation is a bit mixed up. That functionality was deprecated precisely because it WASN'T cross-platform, and there was no way to make it work correctly on all platforms because of how much it was tied to legacy behavior. It never even worked on Mac, and it won't work now on Wayland either, so that's why it's got deprecated and removed. >Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. I have not heard this. I've actually seen great pains being taken to preserve Windows and Mac support in GTK4. For the record I actually think removing something because GNOME doesn't support it would be very valid and wouldn't make them a GNOME-first toolkit. A proper cross-platform toolkit would consider all the supported platforms equally and would support things that can work correctly across all of them, and in this case GNOME happens to be one of those platforms. Remember that they've also deprecated and removed things in the past that didn't work on Windows, such as all the X11-centric stuff that was present in GTK1 and GTK2.
    - rleigh 7y ago
      > functionality was deprecated precisely because it WASN'T cross-platform No, they've deprecated and removed far, far more than that. They've obsoleted and dropped fundamental containers and widgets which have been present right from the 1.x days. These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly. And they even broke compatibility with their UI file formats, with no upgrade path. Upgrading now requires hand-editing huge piles of XML. They could have written some simple XSLT transforms to provide an upgrade path, but they didn't. Or you have to hand-edit all of your sources. Either way, it's painful and with zero added value. I don't expect a competently-maintained library to indulge in such huge breaking changes without a really, really good reason. The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind. It's a huge "screw you" to their actual userbase: application developers.

Can you elaborate? If you're talking about the client-side decorations in GTK, those are up to the app developer to choose if they want them or not.

ori_b 7y ago
As a user, I don't want them, and I don't want the app developer to make that choice for me.
- arghwhat 7y ago
  The developers makes every decision on how an application works and looks (It's part of the code). The top row of pixels is no different.
  - infinity0 7y ago
    It feels like everyone someone voices an opinion about GTK3 explaining why they don't like it, some GTK3 fanboy has to chime in questioning the opinion and implying it isn't rational. Yeah, this makes me want to stick with GTK3 even less. People don't have to explain their preferences in a rational way, they will just switch away from GTK3. It's cheaper. Successful developers will try to interpret these users' feedback in a self-critical, introspective and positive way, and tweak their product based on the feedback. As opposed to continually challenging the giver of the feedback to explain their opinion in more detail, as if by repeatedly digging deeper and deeper into an opinion, you will at some point find some fundamental logical contradiction in their views that will make them re-evaluate their life philosophy on why they just don't like GTK3. I for one think the two opinions given above are perfectly clear ("GTK3 is becoming very GNOME3 specific", "As a user, I don't want them") and can't see why further clarification is being requested. If you really need clarification on these perfectly clear opinions, it is your problem.
    - arghwhat 7y ago
      No clarification at any point was necessary. Despite your rant here, I made no claims as to which was better, or whether a users opinion on that particular aspect was valid. Beauty is in the eye of the beholder, so one cannot claim right or wrong. What I stated was that development decisions, whatever they are, are up to the developers, including which frameworks they wish to use, and how they wish to use them. Saying in any form that you don't want developers to make decisions is nonsensical, as they would not be able to write anything then. Decisions have to be made, compromises chosen, and ultimately, not everyone will get their will. If you don't want other developers to make decisions for you, you're stuck writing all the software you want to use yourself.
      - zapzupnz 7y ago
        > If you don't want other developers to make decisions for you, you're stuck writing all the software you want to use yourself. I suspect this of being as recent an attitude as "no, it's fine that a desktop chat client should take up nearly 4 GB doing absolutely nothing, memory is made to be used". There are enough of us who lived through the days when, no, developers didn't need to make certain decisions for us on the Linux desktop. It wasn't a perfect time but it did exist — as recently as ten years to fifteen years ago in the days of GTK+2 and KDE 3. Again, it wasn't perfect, but those days contradict your assertion. People shouldn't have their opinions discounted because they're no longer in vogue.
    - wruza 7y ago
      I agree. Asking for deep details is like asking “what’s wrong with you” instead of the reverse. Another show stopper for gtk is pretty trivial: it’s a real pain in the ass to get a working set of dlls on windows. The most sane way I know is to incrementally cut it from msys2 installation. That’s plain stupid and is killing an already half-dead framework, which was pretty good at the 2.x days. It locked itself into gnome, which is not even a crushing leader on linux desktops.
      - cycloptic 7y ago
        I haven't tested it but I believe there is a "gtk" package in vcpkg that can be used. Windows support should still work fine, but improving the experience there has never really been a priority simply because of lack of developer interest. Unlike Qt, there is no company behind it, it's open source managed by a non-profit and anyone can work on it. Right now there are only ~2 developers contributing full-time and they work for Red Hat. So unless someone else wants to hire developers to work on it, that's who is calling the shots and they are going to focus on their platform. I also don't really appreciate being called a "fanboy" by the GP. I use Qt as well and I don't favor any framework over another. I'm sticking to the facts here: GTK supports building apps any way you want, not just in the GNOME style. Maybe the problem is that the apps you tried happen to all be GNOME-styled apps. That's a choice that the app developers have to make consciously and has nothing to do with GTK. If there is something else you mean by "locked into GNOME" then please elaborate, because I am having trouble understanding what you're referring to.
  - rixed 7y ago
    The developers of Qt applications do not force how the UI will look like. Users can customize it with local style sheets (usually from the desktop environment).
    - cycloptic 7y ago
      GTK also supports customization via local style sheets. In Qt it's absolutely possible for applications to force client-side decorations and force a certain stylesheet. Maybe it's not common in the apps you use, but again, it's up to the app developer if they want to make use of those things or not.
      - dependenttypes 7y ago
        > GTK also supports customization via local style sheets. They also break them at every release.
        cycloptic 7y ago
        That's just plain FUD. The only release I remember breaking CSS was 3.20, and that was because all the CSS was refactored to allow for way more theming possibilities. Regardless of that I don't see anything based on "cascading styles" as lending itself to a stable theming system anyway. The CSS is probably going to change any time a widget is added/refactored/bugfixed, this holds true on the web as well once you build up a complex library of React components or whatever. The point of it is that there are multiple styles from multiple sources that can cascade together. It's powerful but it can result in a lot of complexity, anyone who's had to add !important directives can attest to that. It needs to be strictly managed by the developers to really work correctly and to prevent the style overrides from getting out of hand. Allowing custom user CSS is only for power users who understand the caveats.
    - arghwhat 7y ago
      You can do that under Gtk3 too, but like with Qt5 it only allows small adjustments in line with how the developers built the UI. You can affect layout and style of certain components, but that's it. From the perspective of making design decisions, it's somewhat equivalent to swapping the phone shell on a Nokia 3310.
  - ptx 7y ago
    What about the filesystem drivers? Should each application developer pick those? Applications run as part of a system that provides certain shared system-wide features and is configured by the user. They should slot into that system.
    - genpfault 7y ago
      > What about the filesystem drivers? Should each application developer pick those? KIO vs GVFS? :)
    - arghwhat 7y ago
      What shared services that are available differs from system to system, just like which are supported differ from applucation to application. Filesystem access may be through an xdg-portal, may support KIO or GVFS integrations, may use framework internal pickers, and so forth. Many decisions for the developers to make. Filesystem drivers are much further down the stack, but that's just a different group of developers making all the decisions.
- cycloptic 7y ago
  A toolkit unfortunately can't enforce that. You have to ask the app developers to change their design.
  - ori_b 7y ago
    Sure it can. Until fairly recently, client side decorations were simply unsupported, and things worked better.
    - cycloptic 7y ago
      No, they were always supported in the sense that it has always been possible to make a frameless window and draw your own decorations. In the old days this was even a highly desired thing for Audacious/Beep/XMMS because of compatibility with Winamp skins, which all included their own graphics for window decorations. The only thing that has become supported in GTK fairly recently is a common appearance for them. If you notice more app developers happening to use them lately, that's a different issue driven by design trends, not by what some toolkit decides to support. Technically speaking, CSD is not exactly a new thing and has been the norm on Windows and Mac for quite a long time now. Design-wise, the practice of putting widgets into the title bar is what app developers are wanting now. Have you noticed the UI in the newest Chrome? Or iTunes? All the topmost widgets are moved up into the title bar. This is where we are headed at the moment.
      - ori_b 7y ago
        It's been theoretically possible for a while, but hard to do, as well as being considered antisocial. It's quite a new regression on Mac as well.
        cycloptic 7y ago
        It was not hard to do, it's as trivial as drawing 2 buttons and some text. If this is such an issue then take it up with all the app developers. See for yourself how well they respond to accusations of being "antisocial" just for the act of moving some buttons up 30 pixels. This isn't a new thing or a regression on Mac, they always had CSD, even in the pre-OS X days. What is trendy there now is the merging of the toolbar and titlebar, which is different.
guug 7y ago
They deprecated functionality that no longer fit GNOME's workflow even if it is when it's still needed on other desktops and operating systems (see systray icons[1]). Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. Relying on GTK to be a cross-platform GUI toolkit is very risky given its current direction. [1]: https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html
- cycloptic 7y ago
  I don't see how that follows and I think your explanation is a bit mixed up. That functionality was deprecated precisely because it WASN'T cross-platform, and there was no way to make it work correctly on all platforms because of how much it was tied to legacy behavior. It never even worked on Mac, and it won't work now on Wayland either, so that's why it's got deprecated and removed. >Their developers stated on more than one occasion that GTK is a GNOME-first toolkit. I have not heard this. I've actually seen great pains being taken to preserve Windows and Mac support in GTK4. For the record I actually think removing something because GNOME doesn't support it would be very valid and wouldn't make them a GNOME-first toolkit. A proper cross-platform toolkit would consider all the supported platforms equally and would support things that can work correctly across all of them, and in this case GNOME happens to be one of those platforms. Remember that they've also deprecated and removed things in the past that didn't work on Windows, such as all the X11-centric stuff that was present in GTK1 and GTK2.
  - rleigh 7y ago
    > functionality was deprecated precisely because it WASN'T cross-platform No, they've deprecated and removed far, far more than that. They've obsoleted and dropped fundamental containers and widgets which have been present right from the 1.x days. These changes represent hard compatibility breaks, each and every one of them. As an application developer, these are not improvements, but very costly. And they even broke compatibility with their UI file formats, with no upgrade path. Upgrading now requires hand-editing huge piles of XML. They could have written some simple XSLT transforms to provide an upgrade path, but they didn't. Or you have to hand-edit all of your sources. Either way, it's painful and with zero added value. I don't expect a competently-maintained library to indulge in such huge breaking changes without a really, really good reason. The old functionality could have been retained, implemented entirely in terms of the new, but they just had to rip it all out for the sake of it. That's not maintenance with end developers in mind. It's a huge "screw you" to their actual userbase: application developers.