GUI development with Rust and GTK 4 • Hacker News Board

Re: GUI development with Rust and GTK 4

#151

Post by rvz » Wed, Apr 26, 2023, 10:45 AM UTC

TingPing wrote: post #145

rvz wrote: post #60

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.

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.

Re: GUI development with Rust and GTK 4

#152

Post by nextaccountic » Wed, Apr 26, 2023, 2:05 PM UTC

mixedCase wrote: post #13

nextaccountic wrote: post #3

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/

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 rea…

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?

Re: GUI development with Rust and GTK 4

#153

Post by u9OEYkI0bUxuGns » Wed, Apr 26, 2023, 2:14 PM UTC

chrismorgan wrote: post #149

u9OEYkI0bUxuGns wrote: post #124

Earlier quoted context omitted.

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 ca…

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 com…

>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.

Re: GUI development with Rust and GTK 4

#154

Post by rollcat » Wed, Apr 26, 2023, 3:39 PM UTC

u9OEYkI0bUxuGns wrote: post #122

rollcat wrote: post #114

Earlier quoted context omitted.

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 s…

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…

> 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.

Re: GUI development with Rust and GTK 4

#155

Post by chrismorgan » Wed, Apr 26, 2023, 4:21 PM UTC

rollcat wrote: post #154

u9OEYkI0bUxuGns wrote: post #122

Earlier quoted context omitted.

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…

> 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…

I’m now curious whether Emacs key bindings work in GTK text boxes on macOS.

Re: GUI development with Rust and GTK 4

#156

Post by 3836293648 » Wed, Apr 26, 2023, 4:50 PM UTC

captainmuon wrote: post #80

nu11ptr wrote: post #4

AFAIK, for better or worse, this is the only UI crate (other than HTML-like UI using something like Tauri) that provides a full set of widgets/capabilities on Rust. Every other UI lib is incomplete in some way or falls short for anything other than a toy or specialty type app in my experience. 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…

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 too…

Just to nitpick, gtk looks native in GNOME

Re: GUI development with Rust and GTK 4

#157

Post by u9OEYkI0bUxuGns » Wed, Apr 26, 2023, 5:26 PM UTC

rollcat wrote: post #154

u9OEYkI0bUxuGns wrote: post #122

Earlier quoted context omitted.

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…

> 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…

>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.

Re: GUI development with Rust and GTK 4

#158

Post by mixedCase » Thu, Apr 27, 2023, 12:25 AM UTC

nextaccountic wrote: post #152

mixedCase wrote: post #13

Earlier quoted context omitted.

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 rea…

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?

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.

Re: GUI development with Rust and GTK 4

#159

Post by galangalalgol » Thu, Apr 27, 2023, 12:50 AM UTC

chrismorgan wrote: post #150

galangalalgol wrote: post #134

Earlier quoted context omitted.

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 i…

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.

Re: GUI development with Rust and GTK 4

#160

Post by chrismorgan » Thu, Apr 27, 2023, 5:52 AM UTC

galangalalgol wrote: post #159

chrismorgan wrote: post #150

Earlier quoted context omitted.

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 i…

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.