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...
GUI development with Rust and GTK 4
91–100 of 172 posts
Re: GUI development with Rust and GTK 4
#92Earlier quoted context omitted.
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…
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 f…
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.
Re: GUI development with Rust and GTK 4
#93Earlier quoted context omitted.
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 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").
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.
Re: GUI development with Rust and GTK 4
#94While 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.
Re: GUI development with Rust and GTK 4
#95Earlier quoted context omitted.
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.
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.
Re: GUI development with Rust and GTK 4
#96Earlier quoted context omitted.
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 f…
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 o…
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.
Re: GUI development with Rust and GTK 4
#97AFAIK, 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…
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.
Re: GUI development with Rust and GTK 4
#98Earlier quoted context omitted.
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 t…
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,…
>Native look and feel is vastly overrated imo.
Case in point: Blender has an outstanding GUI toolkit, non-native.
Re: GUI development with Rust and GTK 4
#99AFAIK, 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…
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.
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.
Re: GUI development with Rust and GTK 4
#100Would 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.