GUI development with Rust and GTK 4(gtk-rs.org)
gtk-rs.org
GUI development with Rust and GTK 4
https://gtk-rs.org/gtk4-rs/stable/latest/book/hello_world.html
170 comments
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.
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.
> 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
It's being worked on.
https://twitter.com/paulrouget2/status/1595357518913449992
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.
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.
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.
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.
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
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
>You’re viewing things from the wrong angle.
Nope, the onus is always on the app developer. Even Microsoft is inconsistent with their own Windows apps using overlay scrollbars. Old Windows apps don't have them, but the new app guidelines for Windows 11 actually say you should use overlay scrolling: https://learn.microsoft.com/en-us/windows/apps/design/contro...
Windows developers just have to pick which guidelines they want to follow, that's how it goes. I don't know the specifics of keyboard interactions but I'd imagine it also changes over time in Windows and varies depending on the app, because that's how everything is in a nearly 40 year old operating system.
I'll steelman your argument anyway: say there was a standard behavior for all of these things. Someone could start doing a lot of testing on Windows and conceivably adding lots of #ifdef _WIN32 to GTK. That isn't particularly hard to do. The problem is then how that affects the apps if the toolkit now has some behaviour that only manifests on Windows. App developers then have to test that and ensure it doesn't break their apps in that specific environment, and if any behaviour is undesired then they have to start adding more #ifdef _WIN32 as well to the apps. Like if an app has a custom text widget or a custom scrollbar, what will they do? You also can't fix that by making them a runtime switch instead of an ifdef. If there was any custom stuff at all, the users and desktops still couldn't override it unless the app developer added another switch.
There just isn't any way around it, the app developer has to handle it. This is a problem with any toolkit that runs on multiple platforms. I can see why you would think it was less of a problem in GTK 2, because less apps were using it so they had less opportunities to make fancy widgets that don't fit in on Windows. Old GTK 2 versions of Inkscape had their own weird bugs, they were just different bugs. None of these can really be fixed in a toolkit, even Qt has problems which you seemed to acknowledge in another comment:
>Of course, other options in a similar space like Qt aren’t entirely better
I've looked through a few of your other comments too and my answer is the same: If you think the direction is bad, then you should show up and start fixing all the open GTK bugs on Windows. Don't just report the bugs, actually fix them. There aren't enough people to even do that, never mind start adding a bunch of extra Windows functionality. And if you do catch up to the point where you can add extra functionality, then you have to stick around for long enough to fix all the new bugs. That's the deal with volunteer projects like GTK: there is no money to hire experts, if you're an expert in Windows development who wants things done then you need to step up and volunteer.
Nope, the onus is always on the app developer. Even Microsoft is inconsistent with their own Windows apps using overlay scrollbars. Old Windows apps don't have them, but the new app guidelines for Windows 11 actually say you should use overlay scrolling: https://learn.microsoft.com/en-us/windows/apps/design/contro...
Windows developers just have to pick which guidelines they want to follow, that's how it goes. I don't know the specifics of keyboard interactions but I'd imagine it also changes over time in Windows and varies depending on the app, because that's how everything is in a nearly 40 year old operating system.
I'll steelman your argument anyway: say there was a standard behavior for all of these things. Someone could start doing a lot of testing on Windows and conceivably adding lots of #ifdef _WIN32 to GTK. That isn't particularly hard to do. The problem is then how that affects the apps if the toolkit now has some behaviour that only manifests on Windows. App developers then have to test that and ensure it doesn't break their apps in that specific environment, and if any behaviour is undesired then they have to start adding more #ifdef _WIN32 as well to the apps. Like if an app has a custom text widget or a custom scrollbar, what will they do? You also can't fix that by making them a runtime switch instead of an ifdef. If there was any custom stuff at all, the users and desktops still couldn't override it unless the app developer added another switch.
There just isn't any way around it, the app developer has to handle it. This is a problem with any toolkit that runs on multiple platforms. I can see why you would think it was less of a problem in GTK 2, because less apps were using it so they had less opportunities to make fancy widgets that don't fit in on Windows. Old GTK 2 versions of Inkscape had their own weird bugs, they were just different bugs. None of these can really be fixed in a toolkit, even Qt has problems which you seemed to acknowledge in another comment:
>Of course, other options in a similar space like Qt aren’t entirely better
I've looked through a few of your other comments too and my answer is the same: If you think the direction is bad, then you should show up and start fixing all the open GTK bugs on Windows. Don't just report the bugs, actually fix them. There aren't enough people to even do that, never mind start adding a bunch of extra Windows functionality. And if you do catch up to the point where you can add extra functionality, then you have to stick around for long enough to fix all the new bugs. That's the deal with volunteer projects like GTK: there is no money to hire experts, if you're an expert in Windows development who wants things done then you need to step up and volunteer.
Certainly some user preferences could damage some apps. But it mostly didn’t, it was generally good enough, and when it did it commonly pointed to a bug in the app anyway (e.g. setting text foreground colour when you don’t know what the background colour is—you must always set (or know the value of) either neither or both). And this flexibility was used by a variety of platforms.
Since you mention overlay scrollbars again, I’ll emphasise something I only alluded vaguely to in my initial wording: GTK does GNOME-style overlay scrollbars. The look and feel are both completely different from Windows 10 and 11 overlay scrollbars, and you certainly can’t accurately emulate the behaviour and I doubt you can emulate the look either. I’ll also mention something that apparently didn’t make it into my previous comment: macOS lets you turn overlay scrollbars on or off at the user level.
As for getting involved: they’ve been actively and deliberately gutting stuff useful for other platforms, and refusing to undelete things because of their vision of how things should be, seen most clearly in how they’ve handled overlay scrollbars and theming. I’m not interested in getting involved with a project like that; it seems to me fairly clearly a lost cause for anything I could do, if I was even willing to spend that kind of time on such a thing.
Since you mention overlay scrollbars again, I’ll emphasise something I only alluded vaguely to in my initial wording: GTK does GNOME-style overlay scrollbars. The look and feel are both completely different from Windows 10 and 11 overlay scrollbars, and you certainly can’t accurately emulate the behaviour and I doubt you can emulate the look either. I’ll also mention something that apparently didn’t make it into my previous comment: macOS lets you turn overlay scrollbars on or off at the user level.
As for getting involved: they’ve been actively and deliberately gutting stuff useful for other platforms, and refusing to undelete things because of their vision of how things should be, seen most clearly in how they’ve handled overlay scrollbars and theming. I’m not interested in getting involved with a project like that; it seems to me fairly clearly a lost cause for anything I could do, if I was even willing to spend that kind of time on such a thing.
>But it mostly didn’t, it was generally good enough, and when it did it commonly pointed to a bug in the app anyway
That hasn't changed though? The individual settings might have changed. Some were added and some were taken away, as is usual in development.
>The look and feel are both completely different from Windows 10 and 11 overlay scrollbars, and you certainly can’t accurately emulate the behaviour and I doubt you can emulate the look either.
If there are subtle things then no you probably can't without writing a new widget. So again, you're talking about having a big #ifdef inside the scrollbar code. Practically speaking the maintainers would then have to maintain at least two separate scrollbar implementations. Those are the Windows 11 scrollbars though, what about the old Win32 scrollbars that are still used in a lot of places? Do you skin them to look and act like Windows 11? 10? 8? Vista? Do you change that at runtime by detecting the OS version? Just looking at the scrollbars on my Win 11 install I see at least 4 different scrollbar styles. So which ones do you support?
Say you decide to go the easy route and only support the default Windows 11 scrollbars with the overlay. Fine. They won't look right if you run them on Windows 10 or 8 but whatever. So when when Microsoft releases a new version or changes the behaviour of the scrollbars, you still have to track that and release a new version in step with Microsoft so it doesn't get out of date. If you want everything to be consistent then you have to do it with every widget, not just scrollbars. That's easily several full time jobs just doing that, which no one has been available to do. Because realistically you need people who are expert Windows developers as well as expert GTK developers, and they have to be willing to volunteer to work for free full time because GTK is a volunteer project. As far as I've seen those people just don't exist.
Really though, I don't think it's as big a problem as you're making it out to be since Windows apps are already widely inconsistent with regard to every widget, including scrollbars.
>macOS lets you turn overlay scrollbars on or off at the user level.
Compared to the work of reimplementing everything, it's not particularly hard to push another boolean setting through the code. It's already there on the app level. But like you say, that wouldn't really solve anything.
>they’ve been actively and deliberately gutting stuff useful for other platforms, and refusing to undelete things because of their vision of how things should be
Every project has a vision of how things should be. That's what separates every project from the rest. That isn't why this is happening though; most of the time they're refusing to undelete things because no one is around to maintain them. You don't just bring code back into the project and suddenly it works, someone has to do actual work to make that happen. If you can make a real good case for bringing back that code, and you can show you'll do the work and you won't disappear, then that person could be you. Currently I don't think any maintainers are Windows developers, they're just trying to keep roughly the same amount of Windows functionality working within the time they have available to work on it. Which is not a lot of time.
But I can see you've already made up your mind that the developers are trying to make things worse for you and sabotage you because they don't like you or something, so I doubt I can convince you of anything. This is why I don't enjoy engaging with this forum often. Have a good one.
That hasn't changed though? The individual settings might have changed. Some were added and some were taken away, as is usual in development.
>The look and feel are both completely different from Windows 10 and 11 overlay scrollbars, and you certainly can’t accurately emulate the behaviour and I doubt you can emulate the look either.
If there are subtle things then no you probably can't without writing a new widget. So again, you're talking about having a big #ifdef inside the scrollbar code. Practically speaking the maintainers would then have to maintain at least two separate scrollbar implementations. Those are the Windows 11 scrollbars though, what about the old Win32 scrollbars that are still used in a lot of places? Do you skin them to look and act like Windows 11? 10? 8? Vista? Do you change that at runtime by detecting the OS version? Just looking at the scrollbars on my Win 11 install I see at least 4 different scrollbar styles. So which ones do you support?
Say you decide to go the easy route and only support the default Windows 11 scrollbars with the overlay. Fine. They won't look right if you run them on Windows 10 or 8 but whatever. So when when Microsoft releases a new version or changes the behaviour of the scrollbars, you still have to track that and release a new version in step with Microsoft so it doesn't get out of date. If you want everything to be consistent then you have to do it with every widget, not just scrollbars. That's easily several full time jobs just doing that, which no one has been available to do. Because realistically you need people who are expert Windows developers as well as expert GTK developers, and they have to be willing to volunteer to work for free full time because GTK is a volunteer project. As far as I've seen those people just don't exist.
Really though, I don't think it's as big a problem as you're making it out to be since Windows apps are already widely inconsistent with regard to every widget, including scrollbars.
>macOS lets you turn overlay scrollbars on or off at the user level.
Compared to the work of reimplementing everything, it's not particularly hard to push another boolean setting through the code. It's already there on the app level. But like you say, that wouldn't really solve anything.
>they’ve been actively and deliberately gutting stuff useful for other platforms, and refusing to undelete things because of their vision of how things should be
Every project has a vision of how things should be. That's what separates every project from the rest. That isn't why this is happening though; most of the time they're refusing to undelete things because no one is around to maintain them. You don't just bring code back into the project and suddenly it works, someone has to do actual work to make that happen. If you can make a real good case for bringing back that code, and you can show you'll do the work and you won't disappear, then that person could be you. Currently I don't think any maintainers are Windows developers, they're just trying to keep roughly the same amount of Windows functionality working within the time they have available to work on it. Which is not a lot of time.
But I can see you've already made up your mind that the developers are trying to make things worse for you and sabotage you because they don't like you or something, so I doubt I can convince you of anything. This is why I don't enjoy engaging with this forum often. Have a good one.
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
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
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.
On Linux, WxWidgets is just a wrapper around GTK or Qt, so it would still inherit all the problems of those toolkits.
> 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/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
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/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
>The concept was never broken on macOS
Yes it is, MacOS also doesn't have key themes. I can't reconfigure a Mac to use Windows keyboard shortcuts. Those are just the default key bindings every Mac app has to support. That's why it works on Mac and it doesn't work on Windows or Linux or anywhere else where the defaults are different. You're comparing apples to oranges here.
To elaborate, Mac gets away with it because historically it has Command as an extra modifier and uses that as the primary modifier key. The Control key isn't used for anything else on Mac. GTK apps need to support non-Mac keyboards where Control is the primary modifier key. The Win or Super key on PC keyboards is historically not used often as a modifier. If it is used as a modifier it's often only used by the shell, not by an app. So, what is consistent for you depends on platform conventions anyway.
>but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
This isn't a desktop preference, you're asking every app to fundamentally change the way its keybindings work. The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs. It doesn't mean that suddenly every preference that you want will start working without any extra effort or causing additional bugs.
Yes it is, MacOS also doesn't have key themes. I can't reconfigure a Mac to use Windows keyboard shortcuts. Those are just the default key bindings every Mac app has to support. That's why it works on Mac and it doesn't work on Windows or Linux or anywhere else where the defaults are different. You're comparing apples to oranges here.
To elaborate, Mac gets away with it because historically it has Command as an extra modifier and uses that as the primary modifier key. The Control key isn't used for anything else on Mac. GTK apps need to support non-Mac keyboards where Control is the primary modifier key. The Win or Super key on PC keyboards is historically not used often as a modifier. If it is used as a modifier it's often only used by the shell, not by an app. So, what is consistent for you depends on platform conventions anyway.
>but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
This isn't a desktop preference, you're asking every app to fundamentally change the way its keybindings work. The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs. It doesn't mean that suddenly every preference that you want will start working without any extra effort or causing additional bugs.
> I can't reconfigure a Mac to use Windows keyboard shortcuts.
Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes about a minute or two, a bit more if you want to change everything as you have to rebind them one by one by hunting down the command names in the menus. You can rebind anything for all apps, or only for a specific app. You can also swap Cmd and Opt. This is probably easier for newbies than editing a text file, but you can't trivially check it into git. I still have a PowerPC Mac with OSX 10.5, I should probably check if it was supported at the time, but my hunch is that it was. The point is it's there, out of the box, and it's working extremely well.
The most interesting thing with this setup is what the terminal does: Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels.
> The Win or Super key on PC keyboards is historically not used often as a modifier.
Yes and no. The scan code is the same as Cmd. If you plug an Apple keyboard to a PC or a PC keyboard to a Mac, the only issue is figuring out if you want to swap it with Alt/Opt.
Cmd/Win has also always been a very popular choice for the "modifier" key in minimalistic/tiling window managers, and GNOME has supported that too, even back in the early 2.x days (I'm not old enough to remember 1.x). Even Windows started using Win-E for things like launching the file manager, Win-P for configuring the screens, Win-arrow keys for window placement, etc - some of that more than 20 years ago IIRC. So it's not like there's no historical precedent, it's always been about conventions, platform defaults, and what do you want to leave up to the user.
I fully agree with "convention over configuration", but if you take away the "configuration" part, what's left is "my way or the highway".
> The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs.
Well, I could argue up until this point, but this is the suckless.org attitude. Awesome. Is this how dwm becomes more user-friendly than GNOME?
FYI I've never had to compile Emacs, Sway, or Alacritty (or ANYTHING on Mac) just to change the key bindings, and I'm definitely the guy who tries to change EVERYTHING.
Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes about a minute or two, a bit more if you want to change everything as you have to rebind them one by one by hunting down the command names in the menus. You can rebind anything for all apps, or only for a specific app. You can also swap Cmd and Opt. This is probably easier for newbies than editing a text file, but you can't trivially check it into git. I still have a PowerPC Mac with OSX 10.5, I should probably check if it was supported at the time, but my hunch is that it was. The point is it's there, out of the box, and it's working extremely well.
The most interesting thing with this setup is what the terminal does: Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels.
> The Win or Super key on PC keyboards is historically not used often as a modifier.
Yes and no. The scan code is the same as Cmd. If you plug an Apple keyboard to a PC or a PC keyboard to a Mac, the only issue is figuring out if you want to swap it with Alt/Opt.
Cmd/Win has also always been a very popular choice for the "modifier" key in minimalistic/tiling window managers, and GNOME has supported that too, even back in the early 2.x days (I'm not old enough to remember 1.x). Even Windows started using Win-E for things like launching the file manager, Win-P for configuring the screens, Win-arrow keys for window placement, etc - some of that more than 20 years ago IIRC. So it's not like there's no historical precedent, it's always been about conventions, platform defaults, and what do you want to leave up to the user.
I fully agree with "convention over configuration", but if you take away the "configuration" part, what's left is "my way or the highway".
> The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs.
Well, I could argue up until this point, but this is the suckless.org attitude. Awesome. Is this how dwm becomes more user-friendly than GNOME?
FYI I've never had to compile Emacs, Sway, or Alacritty (or ANYTHING on Mac) just to change the key bindings, and I'm definitely the guy who tries to change EVERYTHING.
>Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes about a minute or two, a bit more if you want to change everything as you have to rebind them one by one by hunting down the command names in the menus
Sorry I don't count that, this is comparing apples to oranges again. It's still not the same as key themes. You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. It doesn't work either if the command has a slightly different name for some reason. Even if you wanted this type of configuration in GNOME, and if it were even possible, which it sort of is already, it still would be implemented in a completely different way than key themes were. Because key themes were just broken.
The difference is key themes are another thing that claims to do it automatically. If they were working correctly there would be no conflicts. They don't though, so either way if there are conflicts you have to hunt those down and reconfigure every app individually again and then you get to remember which apps have different shortcuts because you had to do something weird to resolve the key conflicts. The point is, I can't just flip a switch that changes everything to Windows shortcuts.
The other issue here is how this relates to GTK and GNOME apps. Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't. So, as always, it still comes back to how the app developer chooses to make the app and what platform conventions they follow. Please be aware of what you're asking for here, it may seem like a simple request to you but when you dig into it it's really asking to change several things in every app to be more like some other platform. And that's not a reasonable request unless you're willing to see it through all the way.
>Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels.
This behaviour is again dependent on how the terminal handles the menu. It could be implemented in a different way where it always interprets it as Copy even when nothing is selected. It won't work at all if you have another key theme where Ctrl-C is an action that's always enabled. And what if I want to rebind SIGINT in this scenario, how does that work? I don't expect terminals to add a menu entry for every terminal escape, but that's how they would have to do it using the Apple approach. Or they have to add their own setting for this, which is no better than before.
>Well, I could argue up until this point, but this is the suckless.org attitude.
No, this is the everything attitude. An app developer can always choose what settings they want to present to the user and what features they want to support. If you don't like it, then yes, most of the time it's "my way or the highway". That's how this software thing works, open source or closed source. Mac, Windows, Linux, all of them have a different collection of settings they support. If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.
Sorry I don't count that, this is comparing apples to oranges again. It's still not the same as key themes. You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. It doesn't work either if the command has a slightly different name for some reason. Even if you wanted this type of configuration in GNOME, and if it were even possible, which it sort of is already, it still would be implemented in a completely different way than key themes were. Because key themes were just broken.
The difference is key themes are another thing that claims to do it automatically. If they were working correctly there would be no conflicts. They don't though, so either way if there are conflicts you have to hunt those down and reconfigure every app individually again and then you get to remember which apps have different shortcuts because you had to do something weird to resolve the key conflicts. The point is, I can't just flip a switch that changes everything to Windows shortcuts.
The other issue here is how this relates to GTK and GNOME apps. Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't. So, as always, it still comes back to how the app developer chooses to make the app and what platform conventions they follow. Please be aware of what you're asking for here, it may seem like a simple request to you but when you dig into it it's really asking to change several things in every app to be more like some other platform. And that's not a reasonable request unless you're willing to see it through all the way.
>Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels.
This behaviour is again dependent on how the terminal handles the menu. It could be implemented in a different way where it always interprets it as Copy even when nothing is selected. It won't work at all if you have another key theme where Ctrl-C is an action that's always enabled. And what if I want to rebind SIGINT in this scenario, how does that work? I don't expect terminals to add a menu entry for every terminal escape, but that's how they would have to do it using the Apple approach. Or they have to add their own setting for this, which is no better than before.
>Well, I could argue up until this point, but this is the suckless.org attitude.
No, this is the everything attitude. An app developer can always choose what settings they want to present to the user and what features they want to support. If you don't like it, then yes, most of the time it's "my way or the highway". That's how this software thing works, open source or closed source. Mac, Windows, Linux, all of them have a different collection of settings they support. If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.
> [...] You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. [...] Because key themes were just broken.
OK so what is the ideal solution in your opinion? If key themes are broken, and having the ability to reconfigure a single key (for any single, or all apps) in a central place is also broken, then what isn't? Hardcoding all key combos in the source? Having every app developer build a custom settings dialog where maybe they will, or maybe they won't let you configure a given shortcut?
> Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't.
You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user.
> It could be implemented in a different way where it always interprets it as Copy even when nothing is selected.
But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels.
> If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.
And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.
OK so what is the ideal solution in your opinion? If key themes are broken, and having the ability to reconfigure a single key (for any single, or all apps) in a central place is also broken, then what isn't? Hardcoding all key combos in the source? Having every app developer build a custom settings dialog where maybe they will, or maybe they won't let you configure a given shortcut?
> Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't.
You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user.
> It could be implemented in a different way where it always interprets it as Copy even when nothing is selected.
But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels.
> If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.
And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.
>OK so what is the ideal solution in your opinion?
Cheeky answer: The ideal solution is a smartphone. It has no keyboard. You don't have to worry about keybindings at all anymore.
Real answer: There isn't one. Once apps can do their own keyboard handling and make their own keybindings, any hope of making a clean solution goes out the window. It's hacks upon hacks from there on, because anything a new app does could potentially conflict with your settings. The Mac solution isn't perfect either but is definitely more flexible and less broken than key themes.
>You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user.
Yes, you're correct. GNOME apps could use the app menu API anyway, the menu wouldn't be visible, but some settings GUI could look at the information exposed by the API and use that to do other things. In practice they don't use that API at all because it has no visible effect for GNOME users, and it's not very compelling to require them to use an API that only adds some actions that are hidden away in a settings panel somewhere. Sure you could change this. But you have to convince every app developer it's a good idea to start doing it when they've already taken a lot of steps to move away from menu bars. Including completely removing them from the HIG. I'm not trying to say this is impossible but it's a major change that will affect every app, and you would have needed to do something similar anyway if you were trying to fix key themes to not be so broken.
>But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels.
No, I've seen plenty of apps where Copy with nothing selected takes some reasonable action. Like if you pressed it after opening a dialog displaying a short document, it could copy the entire document for convenience. I can't say no one will ever come up with some reason to do this in a terminal. If it's a Mac terminal, they have few incentives not to because there isn't a key conflict by default with Ctrl-C. If you go around changing your keybindings and you break that, it's on you. Then you probably want to change it back after you find out it's broken. No one can predict what an app will do, that's the point of letting them handle their own keybindings.
>And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.
By all means, if you like the way Mac handles this, you should use a Mac. Different operating systems are different for a reason.
Cheeky answer: The ideal solution is a smartphone. It has no keyboard. You don't have to worry about keybindings at all anymore.
Real answer: There isn't one. Once apps can do their own keyboard handling and make their own keybindings, any hope of making a clean solution goes out the window. It's hacks upon hacks from there on, because anything a new app does could potentially conflict with your settings. The Mac solution isn't perfect either but is definitely more flexible and less broken than key themes.
>You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user.
Yes, you're correct. GNOME apps could use the app menu API anyway, the menu wouldn't be visible, but some settings GUI could look at the information exposed by the API and use that to do other things. In practice they don't use that API at all because it has no visible effect for GNOME users, and it's not very compelling to require them to use an API that only adds some actions that are hidden away in a settings panel somewhere. Sure you could change this. But you have to convince every app developer it's a good idea to start doing it when they've already taken a lot of steps to move away from menu bars. Including completely removing them from the HIG. I'm not trying to say this is impossible but it's a major change that will affect every app, and you would have needed to do something similar anyway if you were trying to fix key themes to not be so broken.
>But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels.
No, I've seen plenty of apps where Copy with nothing selected takes some reasonable action. Like if you pressed it after opening a dialog displaying a short document, it could copy the entire document for convenience. I can't say no one will ever come up with some reason to do this in a terminal. If it's a Mac terminal, they have few incentives not to because there isn't a key conflict by default with Ctrl-C. If you go around changing your keybindings and you break that, it's on you. Then you probably want to change it back after you find out it's broken. No one can predict what an app will do, that's the point of letting them handle their own keybindings.
>And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.
By all means, if you like the way Mac handles this, you should use a Mac. Different operating systems are different for a reason.
I’m now curious whether Emacs key bindings work in GTK text boxes on macOS.
It's inconsistent. I haven't touched my Gtk settings on macOS, and here are the defaults: Ctrl-A in Gimp (Gtk2) selects all text; in Inkscape (Gtk3) it hops to the start of the line; I'm not sure which apps use Gtk4 so can't tell for this one.
[deleted]
Oh boy, that padding. Could park a lorry in between those list elements.
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.
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?
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).
(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).
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.
[deleted]
Just to nitpick, gtk looks native in GNOME
Is there no Qt bindings for Rust yet?
I think egui is complete enough to use in real apps. Layout can be a bit weird, but I haven't found anything that's impossible.
I might even prefer it for cross-platform apps since startup time is so slow for GTK on Windows.
I might even prefer it for cross-platform apps since startup time is so slow for GTK on Windows.
I use egui for my emulator and it is really good. It's very stable and small enough that you can find your way in without too much searching it. Its speed is pretty fast (I have to render things at under 1/50s).
For me egui, is totally mature as long as you don't need too much. The fun factor induced by the immediate mode and the GL rendering speeds are definitely a plus !
For me egui, is totally mature as long as you don't need too much. The fun factor induced by the immediate mode and the GL rendering speeds are definitely a plus !
egui even has decent accessibility support on Windows and macOS via AccessKit [1]. AFAIK it's the first immediate-mode GUI to implement platform accessibility APIs. The key to that, of course, is that AccessKit creates and updates a retained accessibility tree. I'd like to thank Google for funding most of my work on AccessKit so far, including the egui integration, and Emil (the primary egui developer) for being so receptive to my PRs.
[1]: https://github.com/AccessKit/accesskit
[1]: https://github.com/AccessKit/accesskit
The challenge with egui is the theme. It looks ok, but isn't good enough for a commercial business app for example. Also, I believe it lacks a webview, so if you are in a pinch the only thing you can do is create your own widgets without a way to cheat and embed some web content. I would agree for certain types of apps it may be "good enough" (science, gaming, medical perhaps...anything where the UI is secondary to the 3D viewport)
Native look and feel is vastly overrated imo. Delphi and before it borland builder made for great UIs despite not looking native. To the point that when I came across that widget set, I knew I was in for a good UX. Still many bespoke interfaces, like at a brakes repair or small lumber yard chain use delphi and it works just fine.
As for the webview, thats a thing, but if you will have web access, you can target wasm, and make the egui interface embedded in the webpage instead of the other way round. But yeah, I don't see a webview being part of eframe/egui proper anytime soon because it treats wasm as a tier one target. You might see it supported third party the same way the efile crate supports open file dialogs but only for windows or linux builds.
Edit: dropping the demo link here for people to poke around. I'm curious what people use that is missing, and what people find unsuited to commercial use.
https://www.egui.rs/#Demo
As for the webview, thats a thing, but if you will have web access, you can target wasm, and make the egui interface embedded in the webpage instead of the other way round. But yeah, I don't see a webview being part of eframe/egui proper anytime soon because it treats wasm as a tier one target. You might see it supported third party the same way the efile crate supports open file dialogs but only for windows or linux builds.
Edit: dropping the demo link here for people to poke around. I'm curious what people use that is missing, and what people find unsuited to commercial use.
https://www.egui.rs/#Demo
I mean no offense to the egui people because they have done amazing work, but it isn't that it isn't native, it is that it doesn't look good enough to ship something with it (other than a science/medical/gaming UI perhaps, but certainly not a business app). Gtk won't look native either on anything but Linux...at all, but at least is very professional looking in its default theme. Obviously what looks "good enough" is highly subjective.
UPDATE: True, it is themable, I just wish the default was a little more polished
UPDATE: True, it is themable, I just wish the default was a little more polished
You can skin it fully though. I have an app that looks nothing like the default theme. Customize it to your taste.
Note: I did have to implement some missing features for my purpose, so when I say “fully” I mean I had to spend a couple hours putting the features I wanted together. But in the end, it was a great result. Maybe this work should be turned into a PR, I dunno.
Note: I did have to implement some missing features for my purpose, so when I say “fully” I mean I had to spend a couple hours putting the features I wanted together. But in the end, it was a great result. Maybe this work should be turned into a PR, I dunno.
Good points. It also matures quite quickly and has lots of attention.
I still think the webview thing will be a long time coming if that is something you absolutely need. Best bet is probably something that renders the output of a web engine to gl to stuff in an eguingl window.
I've used such horribly themed business guis that my expectations are probably very skewed. If there are buttons and text windows, and neither of them move when I try to select them, I'll survive. My only explanation is kickbacks to the person that selected their purchase. The worst is when the text entry fields silently sanitize things sent to the server so you don't actually know what went into the database. Well, I guess the worst is that it didn't sanitize the entry at all and some of the characters had special meaning to the ancient backend...
I've used such horribly themed business guis that my expectations are probably very skewed. If there are buttons and text windows, and neither of them move when I try to select them, I'll survive. My only explanation is kickbacks to the person that selected their purchase. The worst is when the text entry fields silently sanitize things sent to the server so you don't actually know what went into the database. Well, I guess the worst is that it didn't sanitize the entry at all and some of the characters had special meaning to the ancient backend...
> Edit: dropping the demo link here for people to poke around. I'm curious what people use that is missing, and what people find unsuited to commercial use.
As I alluded in my other comment, theming is possible but it's really limited if you expect anything close to what you'd typically expect. You can put borders and colors on frames, but it's pretty limited. For example, if you want to have a border with different colors on each edge, or a border on just one edge, you can't do that by default. I had to make a custom frame object that is a frame in a frame to make different sized borders, but it's still a single color.
I created a mockup in PowerPoint (my go to design app... I'm not a designer, but it has everything I need and I know how to use it), and I had a lot of difficulty getting the egui design to match my PP design, because PP actually has a fairly advanced styling engine with a ton of options, and I took advantage of those. So when I go to egui, the default theme didn't support the kinds of design elements I wanted to show.
But, like I said, you can make these things yourself with the egui building blocks without much trouble.
The other thing I found a little frustrating was chromeless windows. There's an example of this, but it didn't seem well supported. The idea is that when you turn off chrome, you can't resize or close your app. So then you have to add all that functionality back. There's a demo that shows this, but it seemed like a pain at the time to integrate into my app. I gave hoping it would be fixed soon, so I will revisit.
As I alluded in my other comment, theming is possible but it's really limited if you expect anything close to what you'd typically expect. You can put borders and colors on frames, but it's pretty limited. For example, if you want to have a border with different colors on each edge, or a border on just one edge, you can't do that by default. I had to make a custom frame object that is a frame in a frame to make different sized borders, but it's still a single color.
I created a mockup in PowerPoint (my go to design app... I'm not a designer, but it has everything I need and I know how to use it), and I had a lot of difficulty getting the egui design to match my PP design, because PP actually has a fairly advanced styling engine with a ton of options, and I took advantage of those. So when I go to egui, the default theme didn't support the kinds of design elements I wanted to show.
But, like I said, you can make these things yourself with the egui building blocks without much trouble.
The other thing I found a little frustrating was chromeless windows. There's an example of this, but it didn't seem well supported. The idea is that when you turn off chrome, you can't resize or close your app. So then you have to add all that functionality back. There's a demo that shows this, but it seemed like a pain at the time to integrate into my app. I gave hoping it would be fixed soon, so I will revisit.
I don't think I know what most people typically expect. I don't know what chrome is, and I'm all for flexibility, but short of some crazy winamp skins in the late 90s, I've never noticed anything being particularly more fancy than amiga500 widgets. Win95 added something. Osx added a bit more, but a box with a label that reverse highlights when I select it is really all I'm expecting.
I rarely create guis, mostly just cli tools. Is there a good intro to basic ui theory so I bdont upset people with higher expectations in the rare event I do create one?
I rarely create guis, mostly just cli tools. Is there a good intro to basic ui theory so I bdont upset people with higher expectations in the rare event I do create one?
"Chrome" is the term for the OS provided border around the window. It offers anchoring points to resize the window; a place to click for dragging; as well as the buttons for closing, maximizing, minimizing. Without chrome, you can't do any of those things, so the window would be fixed in size and place. To get that functionality back, you have to manually code it into the app.
Fun fact: Chrome, the browser, is named ironically. Compared to other browsers at the time, Chrome had almost no chrome around the window content. That was one of the product's signature differences: its UI was so simple that there almost wasn't any UI, allowing users to focus entirely on the content. Thus, calling it Chrome was very funny.
The 2013 Chromebook Pixel followed this naming theme. The screen was so dense that you couldn't see the pixels.
The 2013 Chromebook Pixel followed this naming theme. The screen was so dense that you couldn't see the pixels.
Since you link to the the web demo, I want to caution people: yes, egui can run on the web, but treat that as a demo only done over the web for the convenience of not having to download and run it natively. If you’re making something, do not use egui if you want to actively target the web, because it’s really bad there in fundamentally unfixable ways (given egui’s architecture). Egui is quite compelling on non-web platforms, but it’s not suitable for web content or apps.
More details (including explanation and concrete examples of what’s fundamentally unfixable with egui’s approach to the web, most notably links and scrolling): https://news.ycombinator.com/item?id=33861831
More details (including explanation and concrete examples of what’s fundamentally unfixable with egui’s approach to the web, most notably links and scrolling): https://news.ycombinator.com/item?id=33861831
> only done over the web for the convenience of not having to download and run it natively
Isn't that the entire point of web apps for a lot of people, both users and developers? I'm still planning on implementing a web backend for AccessKit sometime in the next year, to make this type of application ported to the web as accessible as the strongly canvas-based approach will allow.
Isn't that the entire point of web apps for a lot of people, both users and developers? I'm still planning on implementing a web backend for AccessKit sometime in the next year, to make this type of application ported to the web as accessible as the strongly canvas-based approach will allow.
But the fundamental limitations due to mismatched abilities are serious, so that important things are unavoidably just not right in infuriating ways. Games are the only category I can think of where egui can be acceptable on the web.
I didn't have any problems with fonts (I don't block Any), middle clicking opened in a new tab, egui supports context menus, just not the browsers (which is what I want from a webapp).
You’re glossing over the problems.
Font rendering is wrong, even if you aren’t an extremist like me. Stuff is just never going to feel right.
Middle clicking is wrong, it didn’t open in a background tab like it should have, and this is indicative of the fundamental problem, and you couldn’t right click on the link to get the browser’s context menu, which is what you want >99.998% of the time. Browser’s context menu is also rather important in things like text boxes.
Most people won’t be significantly affected by these issues, probably won’t even notice them, or disregard it if they do briefly. But quite a few will loathe your app, because it badly messes up their way of working in ways that no site on the internet does.
Font rendering is wrong, even if you aren’t an extremist like me. Stuff is just never going to feel right.
Middle clicking is wrong, it didn’t open in a background tab like it should have, and this is indicative of the fundamental problem, and you couldn’t right click on the link to get the browser’s context menu, which is what you want >99.998% of the time. Browser’s context menu is also rather important in things like text boxes.
Most people won’t be significantly affected by these issues, probably won’t even notice them, or disregard it if they do briefly. But quite a few will loathe your app, because it badly messes up their way of working in ways that no site on the internet does.
I honestly don't care what font a website uses, if it isn't fuzzy I won't notice it. I really dislike webapps that give me the browser context menu instead of their own custom one. I don't think I'd ever noticed middle click was a background tab, but I can see how that could annoy some people.
The text rendering is fuzzy.
I’m talking about right-clicking on a link, for things like Copy Link, or Open Link in New Private Window. Or in a text box for Cut/Copy/Paste/spell-checking.
I’m talking about right-clicking on a link, for things like Copy Link, or Open Link in New Private Window. Or in a text box for Cut/Copy/Paste/spell-checking.
I need very flexible charting. While egui has some basic stuff builtin, I need something closer to what imgui-charts has (which makes imgui-rs a candidate for me, but probably not egui). A webview would also work as a fallback with a JS charting lib, but egui can't do that either.
Imgui-rs looks really good, thanks! Imgui does say it can output raw vertex buffers, so you could probably put imgui stuff in an egui gl frame and reskin egui to match the looks.
I've only kicked the wheels a bit on egui, but for plotting signals it seemed more than adequate. Its histograms looked fine too. The only thing I saw missing was 3d plotting and heat maps.
I've only kicked the wheels a bit on egui, but for plotting signals it seemed more than adequate. Its histograms looked fine too. The only thing I saw missing was 3d plotting and heat maps.
> I'm curious what people use that is missing, and what people find unsuited to commercial use.
None of the text can be selected in the demo. imo that's a HUGE drawback.
None of the text can be selected in the demo. imo that's a HUGE drawback.
You can only select and copy from text entry fields. Kind of weird for sure. And I can't figure out how to copy even then on mobile.
>Native look and feel is vastly overrated imo.
Case in point: Blender has an outstanding GUI toolkit, non-native.
Case in point: Blender has an outstanding GUI toolkit, non-native.
There are a few categories of apps that can get away with non-native look and feel, or even thrive based upon actively doing their own thing in ways that work better for what they are. Blender is a member of such a category. Most things are not.
(Games are the most obvious category. Blender belongs to what I might call 2D/3D design, a category which would include tools like GIMP, Inkscape, FreeCAD, Photoshop, Illustrator, AutoCAD—all ones that can go fairly fully native, but can also benefit from deliberate deviation in both look and feel.)
(Games are the most obvious category. Blender belongs to what I might call 2D/3D design, a category which would include tools like GIMP, Inkscape, FreeCAD, Photoshop, Illustrator, AutoCAD—all ones that can go fairly fully native, but can also benefit from deliberate deviation in both look and feel.)
Have you seen emilk's own company, https://www.rerun.io/? All build on top of egui! Check out the webviewer on https://app.rerun.io/. It's all open source, https://github.com/rerun-io/rerun.
Concur. I've been using egui for interactive chemistry visualizations, and PC software that interacts with embedded devices to configure them, view system status etc. It's easy-to-use, integrates with 3D graphics easily, and is fast.
Agree with egui, although it is missing some widgets, they’re easy enough to build. But the real killer feature for me is that it’s cross platform including the web. Write once and compile to windows/Mac/Linux/web is finally here through Rust and egui.
I've built apps that compile to windows, Mac, Linux, Android and iOS using Flutter. They perform well and look great.
Qt has supported compilation to web for quite some time now
And when I tried the examples they posted they were massive & laggy.
Yeah, that's the thing that sold me on egui -- the web demo is just buttery smooth, and GPU accelerated.
I had a quick look and it appears that the Linux backend is GTK-3 based? (Requires gtk-3-dev to build.)
Pity. For a moment I was briefly excited that someone had created a Rust binding for EFL/Enlightenment (aka "E").
Pity. For a moment I was briefly excited that someone had created a Rust binding for EFL/Enlightenment (aka "E").
No, egui is an immediate mode framework which draws its own widgets completely using EGL.
GTK is only required if you want the GTK WebView, iirc.
GTK is only required if you want the GTK WebView, iirc.
I would add the following to your list:
- Vizia https://github.com/vizia/vizia
- Freya https://github.com/marc2332/freya
- Xilem https://github.com/linebender/xilem
- Floem https://github.com/lapce/floem
- Vizia https://github.com/vizia/vizia
- Freya https://github.com/marc2332/freya
- Xilem https://github.com/linebender/xilem
- Floem https://github.com/lapce/floem
I'm aware of those, but I don't consider those UI crates in the same way as gtk-rs. The best analogy I can come up with is I don't consider react or vue-js UI libraries either, but low level libraries that can be used to build a UI lib. I consider Material UI (which uses react) to be a UI lib, for example. In the same way, AFAIK these crates are much more concerned with inventing the best UI paradigm than they are at having a full set of widgets useful in creating business apps.
TLDR; I think of these as low level crates, not high level UI crates. If that changes, they will be added to my watch list.
TLDR; I think of these as low level crates, not high level UI crates. If that changes, they will be added to my watch list.
IMO they're just less mature than the one's you've listed. I'd expect them to get all the bells and whistles in due course (assuming that the projects suceed in general).
Do any of them have something remotely close to Gtk or Qt's Grid/TreeView widgets? That's the one thing that pretty much 99% of the software I've worked on have needed at some point
There are plenty of situations where GTK might be better than Slint, but not so overwhelmingly that I'd call it only for toy apps.
While you can create one on your own, any lib that doesn't have a tree widget isn't ready for primetime IMO. Obviously others may have a different opinion. Also, I don't believe there is any way to embed a webview at this point which is often necessary to embed things like charts or other widgets you don't want to create on your own.
GUI toolkits are like MS Word... as the saying goes, everybody only uses 10% but everyone uses a different 10%. This is one of the major things that makes it so hard to have a truly world-class widget set. Making "a" widget set is easy. Making a great one is staggeringly enormous.
I agree - which is why it seems like a better idea to either write bindings to an existing one or use something like Tauri/flutter/etc. It will be VERY hard to both 1) create an adequate UI paradigm in Rust -AND- 2) have a complete widget set large enough to create any business app
Also, tableview/datagrid, complete with support for sorting and reordering items and columns.
It’s shockingly difficult to find newer UI frameworks with this, even though it’s one of the most important desktop UI widgets for a lot of use cases. Win32, Cocoa, GTK, and Qt Widgets have it though, and that’s part of why those toolkits continue to get used.
It’s shockingly difficult to find newer UI frameworks with this, even though it’s one of the most important desktop UI widgets for a lot of use cases. Win32, Cocoa, GTK, and Qt Widgets have it though, and that’s part of why those toolkits continue to get used.
Slint recently added a table widget complete with sorting, which was very welcome
Might be worth adding a "complete widget" flag to areweguiyet.com but I'm fairly sure that's just an invitation to bickering about the definition of "complete" :P
fltk-rs is mature and has a ton of features. Also, its license means that you can bundle it into a single binary without worrying about license contamination.
Thanks for this summary. It’s one thing that’s kept me away from rust and also webassembly in a similar way.
I have not looked, but are there no Qt bindings for rust? Qt is about as complete as they get.
There are but they are not well maintained in general. Some of the bindings require some additional C++ or other painful ways of interop. I have heard some good things about the qmetaobject crate though.
In my limited experience, I would add cacao for MacOS to that list.
I believe that having a common language but using native widgets is the sweet spot for many cross platform projects and teams.
I believe that having a common language but using native widgets is the sweet spot for many cross platform projects and teams.
[deleted]
What about making it easy to import Rust business logic into C# / Swift / whatever GUI language you're using?
I get the value of 100% (or 50% or 80%) implementing the UI in Rust; especially for tools that won't benefit from a native UI, or tools that only need light integration into platform-specific UI features.
I've also shipped a desktop product that had a 100% native UI and a cross-platform codebase. Today, implementing that cross-platform codebase in Rust and then importing it into native C# and Swift codebases for the Mac and Windows variants would be ideal.
I get the value of 100% (or 50% or 80%) implementing the UI in Rust; especially for tools that won't benefit from a native UI, or tools that only need light integration into platform-specific UI features.
I've also shipped a desktop product that had a 100% native UI and a cross-platform codebase. Today, implementing that cross-platform codebase in Rust and then importing it into native C# and Swift codebases for the Mac and Windows variants would be ideal.
No experience with Rust, but for a couple of personal projects I’ve written the logic in Haskell and the GUI in C++ (e.g. https://github.com/bradrn/brassica/blob/master/ARCHITECTURE....). It works pretty well, at least for smaller projects — the basic idea is that the Haskell code gets compiled into a library (static on Windows, dynamic on Linux) which the C++ side can link to. I’d imagine doing the same with Rust would be even easier, since it’s less of a pain to marshal stuff across the language barrier.
I've considered doing this for cross-platform iOS/Android, but the problem there is that by sharing a functional core between platforms you're forfeiting a number of optimizations on iOS (and potentially Android, but everybody brings their own everything there anyway so it's kind of moot).
Point in case, for cross platform networking you're probably pulling in something based on cURL, which is quite functional but as far as I'm aware lacks the optimizations and perks of the iOS networking stack gets you like batching network calls and firing them when the cell antenna is already active to save power, as well as things like transparently multiplexing available connections (e.g. cell and wifi) among other things.
Of course these tradeoffs might make sense sometimes, but I think it's important to recognize that a cross-platform core isn't pure upside.
Point in case, for cross platform networking you're probably pulling in something based on cURL, which is quite functional but as far as I'm aware lacks the optimizations and perks of the iOS networking stack gets you like batching network calls and firing them when the cell antenna is already active to save power, as well as things like transparently multiplexing available connections (e.g. cell and wifi) among other things.
Of course these tradeoffs might make sense sometimes, but I think it's important to recognize that a cross-platform core isn't pure upside.
This is what I do. Is SUPER productive & easy!
I do ALL the UI logic on Rust: Internationalization, formatting, etc and in SwiftUI/JetpackCompose only pain stuff and send/get a single JSON internal FFI endpoint.
So my "records" are just:
I do ALL the UI logic on Rust: Internationalization, formatting, etc and in SwiftUI/JetpackCompose only pain stuff and send/get a single JSON internal FFI endpoint.
So my "records" are just:
App:
{title: "Factura #F10", bg-100:"black", font:"...", ...}
Data:
Invoice {total:"$ 1'000.000,00", ...}
Having integrated C# and Rust recently[0], I have found that unlike Node w/ neon and Python w/ PyO3 + PyO3 Asyncio, there is no good Rust integration with .NET. Interopterus, rnet, etc leave a good bit to be desired.
I ended up writing all the unsafe bindings myself and used cbindgen on the Rust side to make a header and ClangSharpPInvokeGenerator to generate the C# binding. But you still have to manually handle ownership/freeing yourself, e.g. with SafeHandle. The ecosystem[1] could use something better, but nothing is there yet.
0 - https://github.com/temporalio/sdk-dotnet, specifically https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo...
1 - https://areweextendingyet.github.io/
I ended up writing all the unsafe bindings myself and used cbindgen on the Rust side to make a header and ClangSharpPInvokeGenerator to generate the C# binding. But you still have to manually handle ownership/freeing yourself, e.g. with SafeHandle. The ecosystem[1] could use something better, but nothing is there yet.
0 - https://github.com/temporalio/sdk-dotnet, specifically https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo...
1 - https://areweextendingyet.github.io/
That's a good option. It's easy to make a library in Rust that exports a C linkage, and it's easy to link a C library in most languages. Some languages have richer linkages to Rust (for example Python).
A similar option would be to use the native UI with a Rust binding -- for example cacao on MacOS.
The advantage of this approach is if your whole team knows Rust they can help with patching and maintenance. It doesn't help at the beginning because presumably the person who knows AppKit also knows ObjectiveC and/or Swift. But once the UI is created a single code base is an advantage for maintenance.
A similar option would be to use the native UI with a Rust binding -- for example cacao on MacOS.
The advantage of this approach is if your whole team knows Rust they can help with patching and maintenance. It doesn't help at the beginning because presumably the person who knows AppKit also knows ObjectiveC and/or Swift. But once the UI is created a single code base is an advantage for maintenance.
It is really simple to call into native code from C# ( .NET ). While I have not done this with Rust specifically, presenting a C compatible interface from Rust should work fine.
In programming, never make an assumption that something is "easy."
https://news.ycombinator.com/item?id=35701181 did just that and explained the results.
Personally, I find PInvoke time consuming; and often time a lot of people screw it up.
I'm not sure how I'd translate things like lifetimes and ownership into C#: The language just doesn't have those concepts.
Lifetimes might make sense as IDisposable, but that could get tedious. I'd be tempted for types that are just "memory" to have finalizers.
Ownership may require some kind of locking wrapper.
https://news.ycombinator.com/item?id=35701181 did just that and explained the results.
Personally, I find PInvoke time consuming; and often time a lot of people screw it up.
I'm not sure how I'd translate things like lifetimes and ownership into C#: The language just doesn't have those concepts.
Lifetimes might make sense as IDisposable, but that could get tedious. I'd be tempted for types that are just "memory" to have finalizers.
Ownership may require some kind of locking wrapper.
Exposing a C interface from rust is possible, but a bit of a pain.
[deleted]
At this rate programming languages will reinvent GUI builders from Delphi/Lazarus in 2050
I still find it quite sad that the pinnacle of GUI programming tools was reached over 20 years ago, when Delphi 6 was released, and we've been going more or less downhill ever since.
I see it differently: UI needs have gotten more complex. Like how we used to have web sites that said "best viewed in 800x600 in Netscape Navigator" we rarely design one size fits all UIs any more like we did in Delphi.
There's nothing in "modern" UI that cannot be done with Lazarus GUI Builder: Dynamic layouts? check,
anchors? check,
flexbox? check,
custom components? check
nested hierarchies of elements? HIDPI? check
Vector Graphics? check
Multiresolution? check
and so on.
All of them compiled to native (and looking native) on every platform under the sun.
As said before, GUI design peaked in the 90's
Does that extend to internationalisation or accessibility?
(Real questions, Lazarus was before my time)
(Real questions, Lazarus was before my time)
Honestly, all the momentum went to web UIs...desktop UI R&D then just died more or less.
Technically the pinnacle was around 2010.
Guess what happened around that time?
Firstly, the web won.
Secondly, mobile cemented the demise of the desktop.
Especially since mobile is horribly anti-crossplatform GUI toolkit, especially against open source toolkits.
Guess what happened around that time?
Firstly, the web won.
Secondly, mobile cemented the demise of the desktop.
Especially since mobile is horribly anti-crossplatform GUI toolkit, especially against open source toolkits.
Rust GTK4 "hello world" app, as a downloadable project, demonstrating the builder pattern:
https://github.com/SixArm/rust-guideposts/blob/main/projects...
https://github.com/SixArm/rust-guideposts/blob/main/projects...
Honestly this looks like programming style from 90s. Why not design UIs in an editor that saves layout to XML?
Machine generated XML doesn’t play nice with version control for views that are even moderately complex. Merge conflicts become more of a nightmare to untangle as your app matures, plus it can make pull requests unintelligible.
This is part of why for apple platform dev, several years ago I abandoned XML-based XIB and storyboard UI design for any collaborative project. Writing it all out in code (even with just UIKit, no SwiftUI) is a lot more pain-free.
I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework… Jetpack Compose improves the situation some but I’ve not used it much yet.
This is part of why for apple platform dev, several years ago I abandoned XML-based XIB and storyboard UI design for any collaborative project. Writing it all out in code (even with just UIKit, no SwiftUI) is a lot more pain-free.
I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework… Jetpack Compose improves the situation some but I’ve not used it much yet.
> but Google is hellbent on the XML usage if you’re building with Android Framework
That said, folks rarely use the GUI editor for Android XML and managing merges isn't as painful, or really painful at all, when compared to XIBs/storyboards.
Also, as you mentioned, Jetpack Compose obviates that and every new Android view should use it IMO.
That said, folks rarely use the GUI editor for Android XML and managing merges isn't as painful, or really painful at all, when compared to XIBs/storyboards.
Also, as you mentioned, Jetpack Compose obviates that and every new Android view should use it IMO.
Absolutely. XML is rarely a good solution for any problem, and usually the worst.
> I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework…
For sure the Android API is oriented towards building GUIs in XML, but it's actually quite possible to build your Android GUI in Java code.
When I started developing for Android, I took a look at a few tutorials and said "no way", searched the web for how to build Android GUIs programmatically, and never looked back.
> I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework…
For sure the Android API is oriented towards building GUIs in XML, but it's actually quite possible to build your Android GUI in Java code.
When I started developing for Android, I took a look at a few tutorials and said "no way", searched the web for how to build Android GUIs programmatically, and never looked back.
This example shows off the builder style, but since gtk-rs is built on top of GTK, .ui XML files are also supported. You can edit .ui files using the legacy Glade editor (with a conversion script), the newer (but incomplete) Cambalache project, or by hand (it's not that hard and this seems to be the preferred way nowadays)
https://gtk-rs.org/gtk4-rs/stable/latest/book/composite_temp...
https://gtk-rs.org/gtk4-rs/stable/latest/book/composite_temp...
I guess we have come the full circle.
Speaking from a mobile dev's perspective, the native UI design in 2010s was done by XML based files (storybooks in iOS/macOS, XML layout files in Android) and native code would "connect" with the XML files in various ways. Now the development is moving towards declarative approach using frameworks such as SwiftUI and Compose.
This builder pattern resembles quite a bit of how you would declare UI in SwiftUI and Compose.
Speaking from a mobile dev's perspective, the native UI design in 2010s was done by XML based files (storybooks in iOS/macOS, XML layout files in Android) and native code would "connect" with the XML files in various ways. Now the development is moving towards declarative approach using frameworks such as SwiftUI and Compose.
This builder pattern resembles quite a bit of how you would declare UI in SwiftUI and Compose.
> Why not design UIs in an editor that saves layout to XML?
It's funny because that's my personal nightmare. I'm a JS to Rust developer so I'm biased but the likes of React and Svelte have spoiled me with the ease with which you can integrate reactive components into a UI in a way that you simply can't when you're using a separate XML file.
I agree that the example given looks old-school but Rust has a wonderful macro system, I can imagine building a really slick compose method with macros that generates this kind of code underneath.
It's funny because that's my personal nightmare. I'm a JS to Rust developer so I'm biased but the likes of React and Svelte have spoiled me with the ease with which you can integrate reactive components into a UI in a way that you simply can't when you're using a separate XML file.
I agree that the example given looks old-school but Rust has a wonderful macro system, I can imagine building a really slick compose method with macros that generates this kind of code underneath.
I've never seen the appeal of those "write your UI in a different language than the logic and deal with the interference layer" style of GUI development. But I also think that UI builders tend to produce bad code and ugly layouts when you go beyond CRUD apps that would have been easy to write in the declarative style anyway.
One argument I've heard for this model is that, by having the UI in a declarative language, the design team can update/experiment with the layout without having to understand the backing logic. I've only been on one team that actually subscribed to this model though.
I've heard this, but in practice it is hard to fully decouple the interface from the logic so experimentation with the front end usually involves work on the back end. Even simple changes like "we want to change this drop down to a set of radio buttons" ends up requiring changes on the back end most of the time.
I think good tooling support is a requirement for this to work; the one project I used this in (a Silverlight app) had first-class support for this. You could specify separate ViewModels for run time and design time, and the latter would just return static values that the designer could work against. I guess this would require some cursory understanding of C# syntax, but I think the ramp-up for adding/modifying a property would be minimal.
In a project with many developers, it's hard to resolve conflicts with generated XML. For example, iOS and Android have been moving towards a declarative approach with Swift UI / Compose.
XML? That's so ... turn of the century.
Thankfully the industry has mostly woken up from the collective nightmare that was XML.
But apparently a few poor souls are still painfully asleep.
Thankfully the industry has mostly woken up from the collective nightmare that was XML.
But apparently a few poor souls are still painfully asleep.
xml is dated and gross
I really like XML a lot; I've gotten large numbers of people to use XML & XSLT, where I work. XML is dated, and it is gross. Here's the two things the XML ecosystem nailed, which tie me to it:
1. A dedicated tree-based transformation language (XSL); and,
2. Axis-queries (Xpath).
If I could Xpath all-the-things, I'd be a happier human. Although, I also feel like I should be able to SQL all-the-things, too. Maybe I'm just a sucker for structured-data query-languages?
1. A dedicated tree-based transformation language (XSL); and,
2. Axis-queries (Xpath).
If I could Xpath all-the-things, I'd be a happier human. Although, I also feel like I should be able to SQL all-the-things, too. Maybe I'm just a sucker for structured-data query-languages?
Also namespaces. When you need them, you really need them.
XSLT is garbage tho.
XSLT the syntax leaves a bit to be desired. There's also a number of highly questionable default behaviors that are really unfortunate. OTOH, the concept of a term-rewriting tree-matching language is pretty great.
Replace xml with anything else. You're not writing XML. It's just a format used by a layout editor. The issue with this strategy is merge conflicts and diffs that make little sense to a human reviewer.
What about relm4? Is it generally feature complete? Can one use relm4 for most things, and drop to gtk4 for the oddball task that is not supported?
https://relm4.org/
https://relm4.org/
Relm4 is actually based on gtk-rs, and you will be using gtk-rs widgets all the time.
I have to say however that despite heroic efforts by the authors, it doesn't really feel as nice as the "real" Elm architecture precisely because of the imperative focus of gtk-rs' API, the nature of Rust's memory management system, and depending on what you're doing you may feel forced far too often to drop from fantasy land to reap the benefits of the abstraction.
I'd still consider it next time I tackle a native app, but having tried Slint for writing simple UIs and having read some iced code, I think I'd only go for it if I'm really going for the Gtk native look and ecosystem.
I have to say however that despite heroic efforts by the authors, it doesn't really feel as nice as the "real" Elm architecture precisely because of the imperative focus of gtk-rs' API, the nature of Rust's memory management system, and depending on what you're doing you may feel forced far too often to drop from fantasy land to reap the benefits of the abstraction.
I'd still consider it next time I tackle a native app, but having tried Slint for writing simple UIs and having read some iced code, I think I'd only go for it if I'm really going for the Gtk native look and ecosystem.
Yep, relm4 is based on gtk4!
What I am asking is, does relm4 have all gtk4 widgets and is generally feature complete? Is there any reason at all to prefer using gtk4 directly rather than the more ergonomic relm4?
What I am asking is, does relm4 have all gtk4 widgets and is generally feature complete? Is there any reason at all to prefer using gtk4 directly rather than the more ergonomic relm4?
You may have to do some bindings yourself, I remember once looking to try out a libadwaita widget and it wasn't fully supported in the available bindings, don't know about the full library of gtk4-specific widgets.
As for feature complete, depends on your definition. It's on 0.6 and major changes do arrive and updates do break user code, but you certainly can write apps with it.
As for feature complete, depends on your definition. It's on 0.6 and major changes do arrive and updates do break user code, but you certainly can write apps with it.
Don't know relm4, but website says its based on GTK as well
I wondered how Rust would tackle the problem of creating a GUI without C++/Java style inheritance and now I see the answer: you must explicitly compose all "inherited" traits in your subclass. "Unfortunately, nobody found yet a good way to do that. Which is why, as of today, subclassing of GObjects in Rust requires to mention all ancestors and interfaces ..."
You can create UIs entirely out of composition. It's not even that hard, or that foreign per se. The problem you see there is a mismatch between Rust and GTK specifically, not GUIs in general. Of course, all the major GUIs are inheritance based, but I count that as less evidence than I might under other circumstances because GUI toolkits are multi-decade endeavors at the top end, and all the viable ones date to when inheritance was still the Law of the Land.
React is the most interesting GUI approach to me in this regard, as while you can use inheritance if you use the class-based component approach, functional components are, well, functions and can be built by rules of composition. I tend to do a lot of UI in the form of "component with a dozen parameters that almost nobody wants to use every day" that is wrapped by "specialization of the general component that has a few parameters and then uses the general component by wiring those parameters and some logic together."
Any type of "hot patching" is a bit more difficult (I can't easily just reach down a component's tree and mutate it from outside, not unless I've pre-wired the component to allow for that, and the semi-artificial limitation of the use of the tree model as a single `children` property means that such odd wiring gets weird fast if I want to get fancy). But it's a perfectly serviceable UI toolkit framework that is free of requiring inheritance.
ETA: deferring to nu11ptr's taxonomy, React is not a widget toolkit by any means by itself. I find https://react.semantic-ui.com to be perfectly serviceable in that regard as a base, easy-to-modify widget toolkit.
Any type of "hot patching" is a bit more difficult (I can't easily just reach down a component's tree and mutate it from outside, not unless I've pre-wired the component to allow for that, and the semi-artificial limitation of the use of the tree model as a single `children` property means that such odd wiring gets weird fast if I want to get fancy). But it's a perfectly serviceable UI toolkit framework that is free of requiring inheritance.
ETA: deferring to nu11ptr's taxonomy, React is not a widget toolkit by any means by itself. I find https://react.semantic-ui.com to be perfectly serviceable in that regard as a base, easy-to-modify widget toolkit.
React type APIs (e.g. Jetpack Compose too) are interesting but actually I find myself wishing for OOP and inheritance back again. I'd probably quite like a combined approach. Raw functions calling each other have a bunch of weaknesses:
• They aren't really stateless because UI is full of implicit state. So the whole functional UI thing isn't really true. You just end up with odd alternative syntax for what would be object properties, but declared as magical local variables that retain their values across calls.
• No inheritance, interfaces or object identity means no way to write generic code! Want to write a function that locates every button in a UI and applies some behavior to it? Tough, you can't! (in react of course you can drop down to the DOM but in Compose there's no DOM to drop down to). I found this comes up a lot even in simple cases and is a serious limitation.
• "Design systems" (themes) are all custom widgets. There's not really any concept of an underlying widget toolkit with flexible visual styling. Combined with inability to write generic code, it means if you want to port to a different theme or customize anything beyond trivial aspects of the existing theme like font or colors, you have to actually rewrite your code.
• Composition for everything yields enormous amounts of boilerplate. You can't say "define a button that's the same as a regular button except with one additional aspect" and have it automatically stay up to date as the underlying button widget evolves. Instead you have to duplicate the entire API of the button and clone it into your own API, propagating the values by hand.
The annoying thing is that Kotlin already has some features for managing composition, but it requires you to use classes and interfaces. The "everything is a function" philosophy means you lose all those features. Composition also bloats up APIs because there's no longer any distinction between something that's relevant only to people customizing a control (i.e. a protected method) and something that's meant for the user of the control (i.e. a public method or property).
So I'm definitely feeling like sticking my neck out and defending OOP here. Probably there'll be a swing back towards OOP or a similar-but-rebranded form of it in future, as people realize that things like inheritance, subtyping etc were invented for valid reasons.
• They aren't really stateless because UI is full of implicit state. So the whole functional UI thing isn't really true. You just end up with odd alternative syntax for what would be object properties, but declared as magical local variables that retain their values across calls.
• No inheritance, interfaces or object identity means no way to write generic code! Want to write a function that locates every button in a UI and applies some behavior to it? Tough, you can't! (in react of course you can drop down to the DOM but in Compose there's no DOM to drop down to). I found this comes up a lot even in simple cases and is a serious limitation.
• "Design systems" (themes) are all custom widgets. There's not really any concept of an underlying widget toolkit with flexible visual styling. Combined with inability to write generic code, it means if you want to port to a different theme or customize anything beyond trivial aspects of the existing theme like font or colors, you have to actually rewrite your code.
• Composition for everything yields enormous amounts of boilerplate. You can't say "define a button that's the same as a regular button except with one additional aspect" and have it automatically stay up to date as the underlying button widget evolves. Instead you have to duplicate the entire API of the button and clone it into your own API, propagating the values by hand.
The annoying thing is that Kotlin already has some features for managing composition, but it requires you to use classes and interfaces. The "everything is a function" philosophy means you lose all those features. Composition also bloats up APIs because there's no longer any distinction between something that's relevant only to people customizing a control (i.e. a protected method) and something that's meant for the user of the control (i.e. a public method or property).
So I'm definitely feeling like sticking my neck out and defending OOP here. Probably there'll be a swing back towards OOP or a similar-but-rebranded form of it in future, as people realize that things like inheritance, subtyping etc were invented for valid reasons.
Ineritance and subtyping are great for when you want a lot of the code to be "This thing, but a little bit different," and that's a problem that I see come up a lot in GUIs. I'm inclined to agree with the idea that GUIs are one of the better applications for an OOP approach.
Since you mentioned Kotlin, you might be interested in the recent gtk-kn effort which provides OOP bindings to GTK in Kotlin Native. (Early preview, not production ready at all)
https://gitlab.com/gtk-kn/gtk-kn
https://gitlab.com/gtk-kn/gtk-kn
The code to declare/build the widgets is quite nice. Modifying widgets by hand on certain signals or manually re-wiring all the signals seems a bit outdated to me.
Wonder if something like FuncUI [1] could be built on top of it.
[1] https://github.com/fsprojects/Avalonia.FuncUI
Wonder if something like FuncUI [1] could be built on top of it.
[1] https://github.com/fsprojects/Avalonia.FuncUI
Would it be a good idea for a programmer that did not work with Rust before, to dive into GUI programming with GTK4? I'd like to build a simple desktop application for mainly personal use, been dabbling with PyGObject and GJS a bit, but haven't accomplished much yet.
It may be worth noting that GTK, including version 4, doesn't have any accessibility support for Windows or macOS, but only for free desktops using AT-SPI.
Great! So, let's refactor that UI code out into a function. Something a beginner is very likely to do as that code becomes more complex.
Oops. The borrow checker is going to beat you over the head. And beginners aren't likely to understand that it isn't their fault.
Rust needs to figure out a way to do GUIs ergonomically without requiring closures.
Oops. The borrow checker is going to beat you over the head. And beginners aren't likely to understand that it isn't their fault.
Rust needs to figure out a way to do GUIs ergonomically without requiring closures.
Which UI code specifically are you referring to and why would the borrow checker prevent you from factoring it out?
Well, I think the one that stuck out was here:
https://github.com/SixArm/rust-guideposts/blob/main/projects...
But here: https://github.com/gtk-rs/gtk4-rs/blob/master/examples/text_...
and here: https://github.com/gtk-rs/gtk4-rs/blob/master/examples/clock...
The moment some poor slob of a beginner tries to refactor any of those closures into a "normal" function, they're going to get beat over the head by the borrow checker.
Yes, I know why they're required in Rust. And it makes sense once you know Rust well. But a beginner isn't likely to understand why they can't refactor a closure into a function in Rust without a whole lot of clone().
Coding "examples" for Rust need to stop using that closure style--especially in "beginner" code.
But here: https://github.com/gtk-rs/gtk4-rs/blob/master/examples/text_...
and here: https://github.com/gtk-rs/gtk4-rs/blob/master/examples/clock...
The moment some poor slob of a beginner tries to refactor any of those closures into a "normal" function, they're going to get beat over the head by the borrow checker.
Yes, I know why they're required in Rust. And it makes sense once you know Rust well. But a beginner isn't likely to understand why they can't refactor a closure into a function in Rust without a whole lot of clone().
Coding "examples" for Rust need to stop using that closure style--especially in "beginner" code.
If you're like me and like pictures in your books: https://docs.gtk.org/gtk4/visual_index.html
This is a typical code snippet:
final class Gtk.Label : Gtk.Widget implements Gtk.Accessible, Gtk.Buildable, Gtk.ConstraintTarget { /* No available fields */ }
What language is that in?
final class Gtk.Label : Gtk.Widget implements Gtk.Accessible, Gtk.Buildable, Gtk.ConstraintTarget { /* No available fields */ }
What language is that in?
I got flashback memories from my days in Obj-c. I love rust but tend to stay away from reference counting as much as possible :). The first example with the two buttons showed my main annoyance with them. They had to decide which closure keeps a strong reference and which one a weak. A refactor later can be a tricky thing because one always needs to double check again if the reference links are still correct. At least with obj-c these errors will only pop up at runtime.
> At least with obj-c these errors will only pop up at runtime
But it's not a good thing. There's still an error, you're just increasing the chance to miss it.
But it's not a good thing. There's still an error, you're just increasing the chance to miss it.
No I wanted to imply that I actually don’t know how rust handles this case. I think runtime errors are the worst especially with UI. Even when you have a full integration e2e test suite. I take compile errors over runtime errors any day.
What are the disadvantages of using 'static here?
I wonder if a garbage collected language would have a more accurate life time for that object
I wonder if a garbage collected language would have a more accurate life time for that object
‘static is a compile time thing for ensuring memory safety. It doesn’t really have anything to say about when the object will be collected. In fact, since Rust/C/C++ applications use precise garbage collection techniques, they’re going to track the lifetime strictly more accurately than a garbage collected language (which I’m presuming you mean tracing GC). Of course you could have a memory leak / reference cycles but memory leaks are possible with tracing GCs as well (just different kinds of leaks but they are a strict subset of the situations that would cause a leak for things like reference counting iirc).
What lifetimes do let you accomplish is more fearless ownership tracking and letting the compiler expire references for you without needing to use any kind of reference counting. And all things being equal, precise garbage tracking results in lower peak and average memory usage.
What lifetimes do let you accomplish is more fearless ownership tracking and letting the compiler expire references for you without needing to use any kind of reference counting. And all things being equal, precise garbage tracking results in lower peak and average memory usage.
You wonder based on what? Static will put something in the binary itself and it will be memory mapped in, which won't even need to be directly allocated.
The apostrophe isn’t superfluous. ‘Static in this context refers to static lifetime. Lifetimes have absolutely 0 impact on runtime.
How would you get a static lifetime without a static object?
Unrelated to the above convo, but: An owned object can be bound by a static lifetime, for example. Eg, `fn foo<T: 'static>(t: T){}\n foo(String::new());`
More dangerous / less common, but you can also launder lifetimes through unsafe where you use ‘static to indicate “it’s not possible to verify lifetime at compile time but I promise you this will outlive you”. An example of this would be storing a reference that is reference counted but you don’t want the lifetime to bleed out into the type signature.
Box::leak() will make a &'static. You can also use lazy_static! to dynamically make a static global constant.
Box::leak for one.
I'm not sure what this has to do with the parent post or how it contradicts what I said.
https://doc.rust-lang.org/std/keyword.static.html
https://doc.rust-lang.org/std/keyword.static.html
You are referring to static variables which have ‘static lifetime. OP is asking about ‘static lifetime and whether GC would somehow collect garbage more precisely (it wouldn’t). You’re basically talking past each other.
'static is a lifetime here.
Has anyone gotten GTK to compile on Windows without using MSYS? I would love to use pygobject with Python but the build chain and how to get it working is extremely confusing to me. Back in the days of gtk2, pygtk2 used to work wonderfully and compiled with MSVC
It's a hidden gem, but gvsbuild [1] has made it easier again these days - I just discovered it ~a year ago and it's beautiful :)
[1] https://github.com/wingtk/gvsbuild
[1] https://github.com/wingtk/gvsbuild
The documentation looks better than when I was trying to write some Rust with GTK (2020), when it was basically an output of the C functions that could be called...
While I do not, and almost certainly will not, code with Rust, it was very interesting to read this and compare it to doing GUI programming with Gtkmm (the C++ wrapper for GTK), which I've done for more than 20 years.
Some things seem a bit weird and ugly, and some idioms seem rather nice. Overall, not a clear win but certainly worth seeing the differences and similarities and thinking about them a little bit.
Some things seem a bit weird and ugly, and some idioms seem rather nice. Overall, not a clear win but certainly worth seeing the differences and similarities and thinking about them a little bit.
Why use this when it implements one platform's GUI well, and for the others platforms (Windows, macOS) it does it very badly?
At this point, you might as well use Tauri.
At this point, you might as well use Tauri.
Depends on your goal. Linux can be a project’s primary platform, or you can do a native UI on each platform.
Both options are very time consuming and maintenance heavy building a native UI for each platform. If I were to do that, I would target Windows and Mac first since that is where the users are.
Tauri is the obvious choice to target all platforms in the quickest amount of time to market with less native specific maintenance.
Tauri is the obvious choice to target all platforms in the quickest amount of time to market with less native specific maintenance.
You assume every project is commercial. I just make software to solve my problems and I use Linux. GTK is the nicest option to me.
UPDATE: Things I have my eye on as they mature: Slint, egui, and iced. I'm especially watching iced as Pop_os is using it for their DE and likely will add quite a few widgets.