Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUI development with Rust and GTK 4

gtk-rs.org

Post reply on HN
Print view View original

121–130 of 172 posts

Re: GUI development with Rust and GTK 4

#121

Post by kitsunesoba »

gwbas1c wrote: post #57

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

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.

Re: GUI development with Rust and GTK 4

#122

Post by u9OEYkI0bUxuGns »

rollcat wrote: post #114
chrismorgan wrote: post #102

Earlier quoted context omitted.

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

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

Re: GUI development with Rust and GTK 4

#123

Post by mwcampbell »

chrismorgan wrote: post #106
galangalalgol wrote: post #28

Earlier quoted context omitted.

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

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

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

Re: GUI development with Rust and GTK 4

#124

Post by u9OEYkI0bUxuGns »

chrismorgan wrote: post #102
rollcat wrote: post #89

Earlier quoted context omitted.

> 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

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

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.

Re: GUI development with Rust and GTK 4

#125

Post by curt15 »

rollcat wrote: post #89
captainmuon wrote: post #80

Earlier quoted context omitted.

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…

> 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

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?

Re: GUI development with Rust and GTK 4

#126

Post by jandrese »

cglong wrote: post #118
jandrese wrote: post #76

Earlier quoted context omitted.

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.

Re: GUI development with Rust and GTK 4

#127

Post by ModernMech »

galangalalgol wrote: post #67
ModernMech wrote: post #55

Earlier quoted context omitted.

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

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…

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

Re: GUI development with Rust and GTK 4

#128

Post by zorr »

mike_hearn wrote: post #92
shadowgovt wrote: post #46

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

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

Re: GUI development with Rust and GTK 4

#129

Post by e-khadem »

butz wrote: post #100

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.

[dead]

Re: GUI development with Rust and GTK 4

#130

Post by mitchhentges »

pdntspa wrote: post #51

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

Post reply on HN