Our great sponsors
-
-
rust-summaries
Rust summaries are short introductions to Rust programming topics, including the language, ecosystem, concepts, crates, and more.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
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/
Rust GTK4 "hello world" app demonstrating the builder pattern:
https://github.com/SixArm/rust-guideposts/blob/main/projects...
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
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.
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.
0 - https://github.com/temporalio/sdk-dotnet, specifically https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo...
0 -
Since you mentioned Kotlin, you might be interest 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
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
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