6 ms·

For me the litmus test is if it has a fully-featured listview or treeview, so you can do something like a file browser, a library app, or other kinds of data-he

For me the litmus test is if it has a fully-featured listview or treeview, so you can do something like a file browser, a library app, or other kinds of data-heavy apps. Also important is that keyboard and mouse work as expected (tabbing, shift-selection, etc). Bonus if it supports the current "native" OS paradigms. E.g. on Mac: transparent sidebar, integrated titlebar, on Windows: MS office 2022 style simplified toolbar/ribbon, and WinUI styling. Note that even the official modern APIs themselves (SwiftUI and WinUI) don't do everything that first party apps can do. Gtk doesn't look native anywhere but at least it has a very complete widget set and has been around for a while.

nu11ptr 3y ago
Agreed - I'm more and more thinking I'll just use Flutter and use gRPC to talk to a Rust backend. It has native looking widgets for each desktop OS (incl sidebars) if I want to go that way otherwise Material 3 is gorgeous IMO. Once they release the secondary window support I think it will be the best desktop UI framework on the market most likely...as it will look more like the new media centric UIs with nice animation, but with a lower resource usage. (Yes, I know about the rust-dart-bridge or whatever, but gRPC gives my product an API at the same time for "free" and without the complexity of a multi-language project).
rollcat 3y ago
> 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 3y 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 3y 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 3y 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 3y 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.
- kitsunesoba 3y 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 3y ago
  Oh boy, that padding. Could park a lorry in between those list elements.
- curt15 3y 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?
mwcampbell 3y ago
As soon as there's a pure-Rust GUI toolkit with a fully-featured listview or treeview, I'd like to know about it. I'll need to work on support for those widget types in AccessKit pretty soon, and I may need to work with a non-Rust toolkit as my test case for that work.
miohtama 3y ago
Is there no Qt bindings for Rust yet?
deleted 3y ago
[deleted]
3836293648 3y ago
Just to nitpick, gtk looks native in GNOME

nu11ptr 3y ago

Agreed - I'm more and more thinking I'll just use Flutter and use gRPC to talk to a Rust backend. It has native looking widgets for each desktop OS (incl sidebars) if I want to go that way otherwise Material 3 is gorgeous IMO. Once they release the secondary window support I think it will be the best desktop UI framework on the market most likely...as it will look more like the new media centric UIs with nice animation, but with a lower resource usage. (Yes, I know about the rust-dart-bridge or whatever, but gRPC gives my product an API at the same time for "free" and without the complexity of a multi-language project).

rollcat 3y ago

> 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 3y 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 3y 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 3y 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 3y 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.
kitsunesoba 3y 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 3y ago
Oh boy, that padding. Could park a lorry in between those list elements.
curt15 3y 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?

mwcampbell 3y ago

As soon as there's a pure-Rust GUI toolkit with a fully-featured listview or treeview, I'd like to know about it. I'll need to work on support for those widget types in AccessKit pretty soon, and I may need to work with a non-Rust toolkit as my test case for that work.

miohtama 3y ago

Is there no Qt bindings for Rust yet?

deleted 3y ago

[deleted]

3836293648 3y ago

Just to nitpick, gtk looks native in GNOME