17 ms·

> Gtk doesn't look native anywhere but at least it has a very complete widget set and has been around for a while. It's being worked on. https://twitter.com/p

> Gtk doesn't look native anywhere but at least it has a very complete widget set and has been around for a while. It's being worked on. https://twitter.com/paulrouget2/status/1595357518913449992 https://twitter.com/paulrouget2/status/1595357518913449992

chrismorgan 4y ago
I’m curious about this, because over the past decade or so, large parts of GTK’s cross-platform ability have been actively sabotaged. It used to be possible to style it to look native on Windows, with some feel problems but mostly comparatively minor. Now, well, no one has quite managed native look (whether or not it’s possible, and certainly I’ll allow that “native” is very ill-defined on Windows these days), and feel is way off in important ways because they’ve deliberately removed a number of important pieces, forcing GNOME HIG conventions. (Things like how they basically force GNOME’s style of overlay scrollbars these days; also keyboard stuff is regularly hopelessly wrong.) The GTK/libadwaita separation is a lie. The GNOME Foundation co-opted GTK and deliberately scupper it for everyone that’s not GNOME (whether on Linux or for other OSes). So I’m curious whether this sort of patch would be accepted. Assuming reasonable quality of patch, it pretty obviously should be if you want to be a cross-platform toolkit that doesn’t feel massively out of place, but without knowing what position or connections Paul Rouget may have, I’m honestly sceptical that such a patch would be accepted.
- rollcat 4y ago
  Unfortunately I agree with your analysis, I feel like GNOME is sabotaging not only the other platforms, but its own native one as well[1], to the detriment of the broader FOSS ecosystem. On the other end you have extreme minimalism like dwm, and the middle-ground like lxqt always felt lacking in polish. What's the state of wxWidgets nowadays? I feel like they've always had the most honest approach to cross-platform support. [1]: https://news.ycombinator.com/item?id=35650663#35653129 https://news.ycombinator.com/item?id=35650663#35653129
  - u9OEYkI0bUxuGns 4y ago
    Nothing was sabotaged there. Custom key themes were removed because the whole concept of them was broken. The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. It would get even worse if you had your own custom key theme, there's nothing reasonable an app can do when you add a bunch of key binds that break its keys. On Linux, WxWidgets is just a wrapper around GTK or Qt, so it would still inherit all the problems of those toolkits.
    - rollcat 4y ago
      > Custom key themes were removed because the whole concept of them was broken. The concept was never broken on macOS. It's also implemented in a brilliantly simple and very user-accessible way, and requires very little consideration from the application developer. Between that, or having a single configuration file where one can achieve a similar result, deciding which method is better probably boils down to personal preference. No more personal preference for me though. > The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. Again, macOS does effectively have what can be summarised as "Emacs keybindings": C-a, C-k, C-b, etc all do what you expect them to do, and if you do ever find any particular key combo conflicting for some obscure reason, you have a simple, system-level tool to fix it. I know the issue under GNOME mostly comes from trying to find a compromise between copying what Windows does, and what's native to the terminal, but all I'm really trying to achieve is to have a consistent working environment. The way things are: in the terminal, Ctrl-C sends an interrupt, and Ctrl-Shift-C (or some other combination, depending on your terminal emulator) copies text; in Emacs C-c is a command prefix, and M-w is copy; etcetera. I find working like this frustrating; I could probably stomach having Ctrl-C as copy everywhere (even if it meant doing something unspeakable to the terminal emulator to keep the ability to send SIGINT to the foreground process), but I used to be able to whackamole every app into respecting my preference for using Cmd-C for that. Switching between all these conventions is unnecessary mental fatigue. I know my argument is pretty much <https://xkcd.com/1172/ https://xkcd.com/1172/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
- deleted 4y ago
  [deleted]
- u9OEYkI0bUxuGns 4y ago
  This comment is not correct. GNOME Foundation didn't co-opt or sabotage GTK. For a very long time it's just been mostly GNOME people contributing. It's a known problem that GTK needs more people contributing to fix issues on other platforms. No one I've talked to at the Foundation is happy about this either. If you're bothered about this, you should consider showing up and start contributing. GTK4 and Adwaita apps can still be styled however the developer wants. If some app developer wants to make a Windows theme, go for it. Overlay scrollbars aren't forced. The app developer can disable that and make the scrollbars always show. You might not want to though, because some Windows apps do have overlay scrollbars. For example: VS Code. Keyboard shortcuts are also up to the app developer. If someone wants to have some compile time setting to change the keybinds when building on Windows, go for it. I have no idea what you're saying about libadwaita separation. You can very clearly look at the libadwaita code and see what's in there versus what gets upstreamed into GTK. No one has any way to lie here. It's just an extra set of GTK widgets you can optionally use. The draft MR written by Paul is still open. I doubt it will be merged in the current state it's in, because it has bugs.
  - chrismorgan 4y ago
    You’re viewing things from the wrong angle. To begin with, the onus of all of these things has been shifted to the app developer. Previously, a lot of it was up to the user or the desktop environment. I said “basically force” because non-overlay scrollbars are possible, but getting them requires every app’s developer to change the property everywhere. If (I recall correctly, it’s not even a theme thing.) That’s completely unrealistic, quite apart from there being no convention. Firefox gets an “always show scrollbars” checkbox in its preferences, which you can manually tick; but I haven’t come across anything else exposing it. Keyboard: I wasn’t speaking of keyboard shortcuts, actually but other details like what arrow keys do, how text is selected by keyboard (e.g. Ctrl+Shift+Left/Right: which punctuation marks word boundaries, what punctuation or whitespace do you include in the direction of selection). Windows has strong conventions on how those sorts of things work, and my recollection is that GTK does things the GNOME way rather than the Windows way when on Windows. libadwaita: they said “we’ve split out GNOME HIG stuff into libadwaita, GTK is now more platform-neutral”. In practice, compared to GTK+ 2, even more GNOME HIG is baked into GTK, even more strongly: in the past, users and desktop environments could override various of the stuff; now, the app developer has to support it, or you have to maintain increasingly onerous patches against their source code. That’s the problem. As for what’s in libadwaita, it’s mostly just a few widgets, and various functionality such as colouring stuff that seems to me to pretty clearly belong in libgtk (because it’s useful almost everywhere, and other platforms have analogues which you want to be supported out of the box). I’ve written more about the bad direction GTK has headed in: https://hn.algolia.com/?query=chrismorgan+gtk&type=comment https://hn.algolia.com/?query=chrismorgan+gtk&type=comment
kitsunesoba 4y ago
That's a great start, much better than I would've expected, but padding definitely needs work. Modern macOS and iOS use more whitespace than prior versions but not nearly that much… the padding shown here should be cut down to maybe 25-50% of present values depending on the exact part.
HeckFeck 4y ago
Oh boy, that padding. Could park a lorry in between those list elements.
curt15 4y ago
Microsoft or Apple don't invest any effort in making their toolkits look native or even work on other platforms. Would GTK benefit from directing 100 percent of its already limited developer resources and money on Linux?

chrismorgan 4y ago

I’m curious about this, because over the past decade or so, large parts of GTK’s cross-platform ability have been actively sabotaged. It used to be possible to style it to look native on Windows, with some feel problems but mostly comparatively minor. Now, well, no one has quite managed native look (whether or not it’s possible, and certainly I’ll allow that “native” is very ill-defined on Windows these days), and feel is way off in important ways because they’ve deliberately removed a number of important pieces, forcing GNOME HIG conventions. (Things like how they basically force GNOME’s style of overlay scrollbars these days; also keyboard stuff is regularly hopelessly wrong.) The GTK/libadwaita separation is a lie. The GNOME Foundation co-opted GTK and deliberately scupper it for everyone that’s not GNOME (whether on Linux or for other OSes). So I’m curious whether this sort of patch would be accepted. Assuming reasonable quality of patch, it pretty obviously should be if you want to be a cross-platform toolkit that doesn’t feel massively out of place, but without knowing what position or connections Paul Rouget may have, I’m honestly sceptical that such a patch would be accepted.

rollcat 4y ago
Unfortunately I agree with your analysis, I feel like GNOME is sabotaging not only the other platforms, but its own native one as well[1], to the detriment of the broader FOSS ecosystem. On the other end you have extreme minimalism like dwm, and the middle-ground like lxqt always felt lacking in polish. What's the state of wxWidgets nowadays? I feel like they've always had the most honest approach to cross-platform support. [1]: https://news.ycombinator.com/item?id=35650663#35653129 https://news.ycombinator.com/item?id=35650663#35653129
- u9OEYkI0bUxuGns 4y ago
  Nothing was sabotaged there. Custom key themes were removed because the whole concept of them was broken. The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. It would get even worse if you had your own custom key theme, there's nothing reasonable an app can do when you add a bunch of key binds that break its keys. On Linux, WxWidgets is just a wrapper around GTK or Qt, so it would still inherit all the problems of those toolkits.
  - rollcat 4y ago
    > Custom key themes were removed because the whole concept of them was broken. The concept was never broken on macOS. It's also implemented in a brilliantly simple and very user-accessible way, and requires very little consideration from the application developer. Between that, or having a single configuration file where one can achieve a similar result, deciding which method is better probably boils down to personal preference. No more personal preference for me though. > The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. Again, macOS does effectively have what can be summarised as "Emacs keybindings": C-a, C-k, C-b, etc all do what you expect them to do, and if you do ever find any particular key combo conflicting for some obscure reason, you have a simple, system-level tool to fix it. I know the issue under GNOME mostly comes from trying to find a compromise between copying what Windows does, and what's native to the terminal, but all I'm really trying to achieve is to have a consistent working environment. The way things are: in the terminal, Ctrl-C sends an interrupt, and Ctrl-Shift-C (or some other combination, depending on your terminal emulator) copies text; in Emacs C-c is a command prefix, and M-w is copy; etcetera. I find working like this frustrating; I could probably stomach having Ctrl-C as copy everywhere (even if it meant doing something unspeakable to the terminal emulator to keep the ability to send SIGINT to the foreground process), but I used to be able to whackamole every app into respecting my preference for using Cmd-C for that. Switching between all these conventions is unnecessary mental fatigue. I know my argument is pretty much <https://xkcd.com/1172/ https://xkcd.com/1172/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
deleted 4y ago
[deleted]
u9OEYkI0bUxuGns 4y ago
This comment is not correct. GNOME Foundation didn't co-opt or sabotage GTK. For a very long time it's just been mostly GNOME people contributing. It's a known problem that GTK needs more people contributing to fix issues on other platforms. No one I've talked to at the Foundation is happy about this either. If you're bothered about this, you should consider showing up and start contributing. GTK4 and Adwaita apps can still be styled however the developer wants. If some app developer wants to make a Windows theme, go for it. Overlay scrollbars aren't forced. The app developer can disable that and make the scrollbars always show. You might not want to though, because some Windows apps do have overlay scrollbars. For example: VS Code. Keyboard shortcuts are also up to the app developer. If someone wants to have some compile time setting to change the keybinds when building on Windows, go for it. I have no idea what you're saying about libadwaita separation. You can very clearly look at the libadwaita code and see what's in there versus what gets upstreamed into GTK. No one has any way to lie here. It's just an extra set of GTK widgets you can optionally use. The draft MR written by Paul is still open. I doubt it will be merged in the current state it's in, because it has bugs.
- chrismorgan 4y ago
  You’re viewing things from the wrong angle. To begin with, the onus of all of these things has been shifted to the app developer. Previously, a lot of it was up to the user or the desktop environment. I said “basically force” because non-overlay scrollbars are possible, but getting them requires every app’s developer to change the property everywhere. If (I recall correctly, it’s not even a theme thing.) That’s completely unrealistic, quite apart from there being no convention. Firefox gets an “always show scrollbars” checkbox in its preferences, which you can manually tick; but I haven’t come across anything else exposing it. Keyboard: I wasn’t speaking of keyboard shortcuts, actually but other details like what arrow keys do, how text is selected by keyboard (e.g. Ctrl+Shift+Left/Right: which punctuation marks word boundaries, what punctuation or whitespace do you include in the direction of selection). Windows has strong conventions on how those sorts of things work, and my recollection is that GTK does things the GNOME way rather than the Windows way when on Windows. libadwaita: they said “we’ve split out GNOME HIG stuff into libadwaita, GTK is now more platform-neutral”. In practice, compared to GTK+ 2, even more GNOME HIG is baked into GTK, even more strongly: in the past, users and desktop environments could override various of the stuff; now, the app developer has to support it, or you have to maintain increasingly onerous patches against their source code. That’s the problem. As for what’s in libadwaita, it’s mostly just a few widgets, and various functionality such as colouring stuff that seems to me to pretty clearly belong in libgtk (because it’s useful almost everywhere, and other platforms have analogues which you want to be supported out of the box). I’ve written more about the bad direction GTK has headed in: https://hn.algolia.com/?query=chrismorgan+gtk&type=comment https://hn.algolia.com/?query=chrismorgan+gtk&type=comment

kitsunesoba 4y ago

That's a great start, much better than I would've expected, but padding definitely needs work. Modern macOS and iOS use more whitespace than prior versions but not nearly that much… the padding shown here should be cut down to maybe 25-50% of present values depending on the exact part.

HeckFeck 4y ago

Oh boy, that padding. Could park a lorry in between those list elements.

curt15 4y ago

Microsoft or Apple don't invest any effort in making their toolkits look native or even work on other platforms. Would GTK benefit from directing 100 percent of its already limited developer resources and money on Linux?