Rust 2021: GUI
raphlinus.github.io
raphlinus.github.io
Oh, this is my post. Never mind, carry on.
More seriously, this was my contribution to the Rust 2021 blogging effort. I didn't really intend for it to be posted to HN, more as in internal discussion within the Rust community. Even so, I'm happy to discuss and answer questions.
Read some more thoughts about Rust 2021 here: https://readrust.net/rust-2021
Some say, use native UI elements, like React-Native.
Some say, render your own stuff in a (GL) canvas, like Flutter/Revery.
WxWidgets (https://en.wikipedia.org/wiki/WxWidgets) 1992
SWT (https://en.wikipedia.org/wiki/Standard_Widget_Toolkit) 2003
Or if you mean React itself, I found this blog post kind of funny: https://www.bitquabit.com/post/the-more-things-change/ :-)
1) data builds the UI
2) widgets, don’t really care if they are native but some building blocks (button, lists, activity indicator etc.) The list from React native will do for now.
3) layout using flexbox and the exact same simplified css with the cascade.
That’s what I’m saying to take anyway.
https://en.wikipedia.org/wiki/Tk_(software)
Perhaps a model similar to Tk could be used?
This is one reason I'm really enjoying Rust. When it comes time to do some platform integration, you just haul out the unsafe keyword and write it, nothing in your way. By contrast, when I was working on Android and had to do a lot of JNI, it was painful.
Attention is always the scarcest resource, all up and down the stack.
Have you given much thought to the design of Druid's accessibility layer yet? I might be able to help with that and with a Windows UI Automation implementation in my spare time (a stable com-rs would help with that). I guess this isn't much of a priority though for your hero app (Runebender).
In any case, I haven't done detailed design work on accessibility, but enough poking around to get some sense of what might be involved.
You are right that stable com-rs will help a lot with this kind of integration; there are soundness and other issues with the custom com implementations we've had to do. Fortunately there are good people working on it.
I agree that accessibility support is a good proxy for maturity. Even if somebody tries to game perception by doing accessibility "early", there are benefits.
On that topic, what are GTK's and Qt's accessibility support like? I remember that once when there was a real prospect of Free Software being made preferred for public acquisitions, somewhere, a big disabled-support group argued that the Free Software stacks lacked accessibility support, and would shut them out. Would such an objection be plausible today?
Windows and Mac has been supported since at least Qt 4 in 2005. I think there was also some support in Qt 3. The archived Qt 4 documentation says X11 support is "preliminary".
- Excellent embedded developer tools. Hundreds of thousands of engineer-hours have gone into the chromium devtools, providing everything from styling overrides to layout metrics to profiling tools to a REPL to DOM tree inspection and modification, to an integrated debugger, etc etc etc, and all of that is at your disposal with a simple Cmd+Opt+I. To my knowledge Rust doesn't have anything like this.
- Super quick incremental updates. Making a change and seeing the impact is sub-second, even on large projects (vscode). Based on my understanding of rust, recompilation can take a very very long time. When making GUI's a lot of the time is spent making finicky little changes and reloading -- if that inner loop is slow you're going to have a bad time.
Compile times have been getting better. For reference, on my machine an incremental build of Runebender is 2.3s. Part of this reflects some choices we've made to use platform capabilities rather than build the entire stack ourselves.
I've developed a Gtk GUI in Rust recently. It wasn't bad, but I probably won't use it ever again. When I'm debugging a UI, I want to right-click it, select Inspect, and be able to tweak everything live.
DevTools is such a force multiplier, that I'm confident I can quickly and reliably develop a whole GUI from scratch, with custom layout animations and bells and whistles using JS+CSS. I have zero confidence in doing anything in Gtk or Cocoa beyond dumping static pre-built controls in a window. The cycle of editing blindly, recompiling, and re-running is the old paradigm that I don't want to return to.
For example, in vscode we do almost everything in TS, but shell out to ripgrep for workspace text search.
Which is quite disappointing, given ripgrep's reputation in search performance.
^well, every issue that isn't completely void of information ;)
GTK_DEBUG=interactive your-app
The Rust semantics also seem to make it quite complex to just drag components around on a GUI designer, because the lifetimes become dynamic and just dropping a component in the middle of a form can have multiple lifetime meanings, depending on the surrounding context.
The tooling is not here yet. But there are drawbacks to using web and flutter is already promising. Any progress in this field should be welcomed by us.
I think the Rust language needs to learn a few tricks from Objective C and Swift to really make this possible. In particular the work being done on extensible protocols.
What you can do, is build a 'Rust-flavored' GUI library. But this isn't what users want: they want a native app, while developers want to write once-run anywhere.
This requires a kind of double decoupling, where UI intent is expressed as an abstraction, and is realized as an OS-native control — but one which itself will dynamically update, insofar as possible, as the OS evolves.
This calls for a kind of API wizardry which Objective C always got right, and C++ never really did. I see that dichotomy extending into Swift and Rust, but it isn't inevitable, Rust hasn't painted itself into that particular corner.
Anyway, it's encouraging to see this work happening, I wish you good fortune in 2021 and beyond.
[1]: https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
Nowadays native apps on Mac are dead. Even Apple is giving up. There are still native-code-running .app bundles, but they're Qt, Electron, or Catalyst that are like knock-off brands of Mac apps. Even if they bother to have vaguely Mac-like skin, they lack all of the nice little details that made Cocoa apps great.
Seems weird to criticize people for working in a way they like to work. The "something better" might just be improved command line tools. I think there's room for both, and different people prefer different types of interfaces.
I'm usually a bit skeptical of current-generation GUIs (but then again, I'm ignorant of the Mac world) largely because it's usually so much more painful to extend and compose them. To pick a perhaps slightly unfair example (since it's basically about text processing), I use Weechat for chat rather than Pidgin, since the UI inconvenience of it being a CLI is outweighed by how easy it is to process my chat history, programmatically interact with notifications, and how much more functional Mosh/SSH are than X11 forwarding.
I know you’re saying that in a subjective way, and definitely the percentage of non-Cocoa apps have gone up, but I’m not sure if they’re dead. In fact, I feel that they are thriving once again in 2020 — a lot of indie devs that care about making Mac-assed Mac apps[0] are present and are releasing great apps and replacing ones that were filled with Electron.
Some examples that pop up in my mind: NetNewsWire 5[1] (an RSS feed reader), Shrungs[2] (a Cocoa Slack client), MimeStream[3] (a Gmail email reader), Chime[4] (a Go IDE that’s entirely Cocoa! I seriously considered learning Go because of this app), ProxyMan[5], and I can go on and on...
My feeling is that Electron got a bit of traction in like 2014~6 but people started to realize they really do like Cocoa better.
[0]: https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
[1]: https://ranchero.com/netnewswire/
[2]: https://shrugs.app/
[5]: https://proxyman.io/
On Windows there are like at least three or four kinds of “native”, I don’t even know what’s “native enough” there.
(Stuff like WPF still has a Win32 L&F, even if it draws the widgets itself, same as Qt.)
Themes: Unstyled Win32, styled Win32, WinForms (which is part Win32 and part custom controls), WPF (which sorta imitates Win32 and doesn't quite look like it), and UWP.
Fonts: Microsoft Sans Serif, Tahoma, Segoe UI, and non-English fonts.
Good luck!
2. The xi-editor project had other problems which I've written about extensively in my retrospective.
3. It's hard to compete against MS VS Code. When I started xi, the competitive landscape had a huge gap between performant and feature-rich but bloated editors.
4. We got funding for the font editor project.
I agree, but as an emacs user that has tried it multiple times, I really don't "get it".
The main thing that excited me about Xi wasn't Xi itself, but rather that its technology stack could be user to "build your own editor" using a solid foundation. That includes a more modern emacs, vi, vs code, or whatever you like.
I reach for C++ and Qt when I want a cross-platform GUI and a low-level, compiled language. If Rust offered something on the same, or at least close, to Qt, I’d go all-in on Rust.
I am kinda hoping autocxx[0] reaches the level of being able to handle wxWidgets headers (I have no hope for Qt though there are multiple Rust projects that try) and that will probably be enough for me on the desktop. Alternatively, it'd be nice to see a project that manually built Qt widget bindings surfacing an idiomatic Rust interface (kinda like what NodeGui does), but it's a lot of manual work that will have limited coverage in early stages instead of just continually improving/tweaking a generator.
I always found that Qt programs end up as their own little dialect of C++ that doesn't quite play by the same rules.
Not really true, because the "interior mutability" pattern allows for mutating structures that are passed via a shared reference. Truly "immutable" data is in fact quite hard to characterize in a language that's as 'low-level' as Rust.
What API alternatives are there to callbacks for widgets that may signal multiple events? One object would be to pass some implementation of some “Events” trait which would have methods to be called for each event kind. This is basically callbacks (I don’t think rust offers a way to make inline trait implementations and I don’t know if there’s a way to implicitly have default implementations that do nothing). This feels similar to in Java where you might subclass Button (I think. It’s been a while since I looked at any Java at all, let alone gui code).
One way to deal with events is a more imgui-like api where you write e.g.
if (make_button("click me")) {
/* just been clicked */
}
Perhaps I should just look at the code to see what Druid and crochet do.
We don't have the one frame latency, as it's not imgui under the hood. (There's a bug in the Crochet prototype on this, but it's known and will be fixed).
Hope this helps clear things up a bit.
These gestures seems not internal to the widgets, but also mutate the widgets state in one way or another and need some abstraction to handle the common behavior.
I did quite a lot of different attempts to GUI Holy Grail in last 20 years ( https://sciter.com/10-years-road-to-sciter/ ) . I am pretty confident that DOM and DOM events is the most flexible (and so robust) foundation so far.
Plenty, decrease in productivity, basically back to Objective-C before GC/ARC, or doing COM in C, lack of support in GUI designers that need to always map to the same types, and building on top of that a big attrition for component libraries.
1. GUI is non-trivial. That is not just about problems of CPU/GPU rasterization (30...40% of all GUI problems). There are others that we usually forget about: accessibility, customization/styling, DPI and screen device size awarness, etc.
2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run.
3. Rust is is not that good to be a language-behind-UI. Ownership graph of GUI objects can be quite complex, contain loops and can be not known at compile time. Something GCable plays significantly better in this respect. That's why JS is so popular in UI. Sciter's script is even better than JS but that's another story.
So "GUI 2021" as a subject of blogging makes sense, but "Rust GUI 2021" is a bit hopeless I think.
Native application is:
1. HTML - declaration of UI structure (think about accessibility here to).
2. CSS - declaration of how that UI structure shall be presented to the user.
3. script - declaration (too, sic!) of how UI structure (a.k.a. DOM) shall be updated in response to user events and application events/state.
4. Native code of application - generates events for UI, provide data to be presented, consumes UI events data updates from UI.
I mean that native languages in Sciter/Rust, Sciter/C++, Sciter/Go applications are talking more with script rather than to particular UI objects. And that script plays a role of declarative/configurational layer translating linear application logic into asynchronous UI concepts. UI and business logic talk with each other in terms of messages - loosely coupled layers, separation of concerns and memory organization, all that.
Disagree. Anything that uses a C ABI has to keep track of ownership externally, and that tends to be error-prone; you end up with excessive copying, leaks, or both. And this is a particularly thorny problem for GUIs because, as you say, ownership of GUI objects can be complicated. So it makes a lot of sense to have a Rust-specific GUI library that leverages Rust's ownership-tracking capabilities to make this easier.
Think about Protocol Buffers (https://developers.google.com/protocol-buffers ) or JSON/BSON as a core of communication protocol
// App side:
window* pw = new Window();
pw->willReceiveMessage("account.modified", cb1);
pw->willReceiveMessage("account.closed", cb2);
pw->willReceiveMessage("account.wantsNew", cb3);
....
pw->loadUI("accounts-view.htm");
....
pw->fireMessage("account.show", accountData: json)
Why not? On UI layer I can always do:
var response = bl.sendMessage("account.validate", accountData);
if( response && response.valid) ...
else if( response && !response.valid )
I am not saying that this is the only way...
In Sciter you can use custom native UI components extending existing DOM - they can handle event, do custom painting, etc. And you can design those components in Rust, C, Go or whatever you like.
var response = bl.sendMessage("account.validate", accountData);
if( response && response.valid) ...
else if( response && !response.valid )
> Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ...
Yes, and the overhead of having to serialise everything is the biggest problem with web UI. If you're going to separate the UI from the business logic like that then why even bother making a native UI at all?
(send-to foo '(:bar 1 "foo"))
(setf val (recv))
(format t "~A~%" val)
(send-to baz `(:thingy ,val))
`(:update (:layout-box (:direction :vertical)
(:layout-box (:direction :horizontal)
(:text-input (:layout (= (width :self) (/ (width :parent) 2))
:contents "Hello, world!"))
(:text (:layout (= (width :self) (/ (width :parent) 2)))
"Hello, world!"))
(:include ,other-actor)))
<div>
<input style="width: 50%;" value="Hello, world!"></input>
<span style="width: 50%;">Hello, world!</span>
</div>
The compositor is in charge of gluing together the tree fragments, laying them out (with Cassowary), "legalizing" them into primitives the current platform supports, and displaying them to the screen. It also sends back input events to the actors involved, probably with some CALL-NEXT-METHOD -like primitive to opt into bubbling.
This lets the compositor operate concurrently with state updates to components, and components to operate concurrently with each other. This is good in the general case of "new processors getting more cores, not higher clocks," and especially since I'm going to be using this mainly on ARM devices, where this is especially true, and being able to split computations to work with big.LITTLE is a huge win for battery life.
I think this also should help quite a bit with ensuring a user interface remains interactive while performing lots of work, if I were to implement preemption (or context switch checks often enough to act like preemption is occurring, like Go has historically had). The only bottlenecks where the whole interface can get stuck are in the compositor, and the only expensive thing there is Cassowary. And if that's fast enough for Apple, it's fast enough for me.
Once this is in a state where I can take pretty screenshots (okay, considering my aesthetic taste, not too pretty...), I'll probably submit a blogpost version of this here with code samples. If you wanna discuss this beyond the length HN makes convenient, feel free to drop me a line on https://lists.sr.ht/~remexre/public-inbox (~remexre/public-inbox@lists.sr.ht).
Long story:
I recently got a PinePhone, and I'm experiencing keyboard latency that makes it incredibly annoying to actually type on it. I only use a small handful of apps on my phone, most of which have CLI or library equivalents, so I figured it wouldn't be that much of a loss to reimplement crappy versions, if I at least had a nice keyboard. (Plus, my old phone isn't actually broken yet, so instability here isn't as big of a problem as it might be otherwise.)
So, I reflashed it to a non-graphical build of Arch Linux ARM, and set up SBCL with Swank on it, with the intent of making a new interface to replace Phosh and the apps that run under it. This has the pretty nice effect that I can live-edit code that's running on the phone itself from Vim on any of my other machines (or even several at once, if I want). Plus, Lisp itself has great performance relative to other languages that provide this level of dynamism. Lastly, since it's set up as a systemd service, even when I mangle EGL state enough to get a segfault, it restarts and generally Just Works Right.
I've been meaning to try out this concept, but always meant to implement a custom language that looks more like Erlang semantically to do it with. Using Lisp lets me buck Greenspun's tenth rule, though, and forces me to avoid spending a year implementing my own efficient code generation. Plus, Lisp already runs great on my phone.
I am probably performing the do-notation transform with a macro, though, to allow for the green thread implementation I need for large numbers of actors. Alternately, I could use cl-cont, but I'm not sure that I want continuations exposed to the programmer.
3. Remains to be seen.
0. Really cross platform: Win, Mac, Linux, Mobiles, IoT.
1. Uses stable (10+ years) and compact API - 30 functions really
2. Uses well known and time proven constructs: HTML/CSS
3. Battle tested, in production since 2006, Sciter UI works on 460 mln PCs and Macs.
Ah, and Sciter/Rust is already here: https://github.com/sciter-sdk/rust-sciter
#2 is nonsense. You assert it makes no sense to invest in only-for-Rust GUI libraries, with no support whatsoever; I flatly disagree. Part of my reasoning is that, if nothing else, an exclusive-to-Rust GUI will be ploughing new ground because of the differences that are forced on the GUI library by the differences in the language, and it will come up with new ideas that will help others in other languages, progressing the state of the art. So yeah, I think it makes a lot of sense, even if it is only available for Rust (though the potential for smooth cross-language operation definitely excites me—I said to Raph a few days ago that I was interested to note that it was actually this that was exciting me the most about the Crochet architecture, that you can have the GUI library in one language and use it entirely from a separate language). But then also as imm says, if you use bindings to something else, you’re throwing away a significant advantage of using Rust. (Similarly, you’ll want to be careful if you’re exposing Rust code to other languages to make sure that you’re not harming either side because of the difference in philosophies.) And if I want to work in Rust, why should I care about C/C++/Delphi? Why should I make compromises on the sort of GUI library I can have just because other languages exist? (Sure, there are definite advantages to pooling resources across language ecosystems, but there are costs as well, that’s my point, and why I think it is unreasonable to say say “it makes no sense” as you did.)
#3 is brimming full of assumptions that there is good cause to suspect are false. You were present in the Towards Principled Reactive UI thread a few days ago (https://news.ycombinator.com/item?id=24599560), which is basically all about developing models that don’t depend on complex ownership graphs. Sure, GC languages work better for the traditional breed of observer-based GUIs, but that’s not the only feasible approach—it’s merely the simplest to implement at the library level, which is why it got so popular. So Rust is probably not a good language for supporting that particular traditional style of UI, but there’s reason to suspect that it may actually be very good for other types of UIs.
I don't know if there would be any meaningful benefits over Electron, but I can see why it might be attractive to build everything in Rust. Seems like you could extend Servo with features required by your app, too.
Projects like ultralight[0] also show there's even much higher room for improvement. That, and libraries like React starting to leverage WASM, and SharedArrayBuffers sharing memory and potentially moving all application logic off-thread (worker-dom is a cool project, I was able to get a medium-size React app fully running with it).
Finally, you could fork Safari and remove quite a few features. A lot of legacy things, simplifying the DOM quite a lot, etc.
If someone did that, I think we'd have a really ideal setup for cross platform apps. A much faster, lighter, smaller bundled app that supported 99% of modern web apps out of the box.
As opposed to writing a new engine from scratch (Servo), I wonder how feasible it would be to fork one of these existing engines and modularize its contents? The ability to start from (close to) zero and then pick and choose which features you want in your engine would be pretty attractive to lots of developers. The application that never expects to play any sort of media or access any peripherals could exclude the respective components from the build entirely.
I've been using Safari more recently and it really is a lot better than Chrome, and especially Firefox. I don't know how Apple does it, but they somehow made a Porsche in an SUV world. Thanks for the ultralig.ht pointer, looks quite interesting!
I'm really curious how you would fork a proprietary project.
> If someone did that, I think we'd have a really ideal setup for cross platform apps.
Buy safari isn't cross-platform.
You’d just need to build a UI.
How does druid test across platforms like the web, Wayland, x11, macOS, Windows, etc? I feel like testing is one of the biggest missing links in the Rust GUI ecosystem right now.
Since then, I've both regretted the fact that we're duplicating work, and been happy that we've been able to move more nimbly than we would if we were dragging the rest of the winit userbase along. A recent example of that is keyboard handling, and I'm expecting a similar situation soon with IME, as we'll want to handle that very differently than winit's current implementation.
Take a look at our CI for the testing story. We have some tests, but they're mostly for platform-independent logic; we don't run a lot of platform specific code in CI. That said, Rust's type system is strong enough to catch a lot of potential breakage at compile time. Other than that, people tend to notice broken things pretty quickly. So overall testing is one of the many things we want to improve, but works reasonably well.
I'm asking partly because I know this stuff is ripe with complexity and edge cases, and also because my head's in that space a bit right now, since I've been slowly fixing a bug in Alacritty that's been driving me crazy with modifiers at startup on X11.
Regarding IME, we haven't done it yet (we're trying to be fairly conservative in our roadmapping), but we plan to wire up actual composition regions and so on, and hope to plumb IME to it using a cross-platform abstraction. My understanding of the winit code is that it varies a lot from platform to platform, but seems to mostly be synthesizing keyboard events (ReceivedCharacter) when an IME request such as "insertText" happens.
If only people had as much energy to help finish/improve existing, usable UI kits instead of re-inventing their own just for the glory of it.
I have no doubt this effort will end up in the same exact way as the xi-editor (https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...) - a Rust text editor - did: huge amounts of work spent reinventing the wheel, one or two minor original contributions, but ultimately, ending far short of its goals and not delivering anything.
If I were to try and write a cross-platform single-binary 2D GUI application with rust these days, it's the first thing I'd pick. Unfortunately, I haven't done that, so whether it's the right choice for you is still up for debate.
There's also stuff like gtk-rs[2] for those who want to have a bit more of a trusted gtk-flavored ecosystem.
[0]: https://docs.rs/conrod_core/0.70.0/conrod_core/guide/chapter...
[1]: https://github.com/PistonDevelopers/conrod
[2]: https://gtk-rs.org/
Debugging Rust code in VSCode with Rust-analyzer and LLDB works pretty flawlessly for me, and it understands and displays all the types/values in the GUI so you don't really need expression evaluation.
In some sense, the rendering API is the hard part of trying to build your own GUI toolkit.
That kind of defeats the purpose?
> Alternatively, there is an X11 backend available, although it is currently missing quite a few features.
It would be good to also support Wayland compositors without GTK.
Which purpose?
* I hope it will become a viable alternative to C/C++ for graphics programming. Unfortunately, last I checked as of ~6 months ago, Rust graphics libraries are still in their infancy.
* I hope it will eventually replace Electron as the go-to for multiplatform app development. IMO this cannot realistically be done by relying on native APIs / platform-specific tools like GTK, since we need something closer to functional reactive programming a la React/Svelte/SolidJS, with more emphasis on performance. If I wanted to build a GTK app, I would build a GTK app. See also [1].
I believe Rust has the potential to accomplish both goals, partially due to the design of the language, but mostly because I have faith in the very smart people who work on Rust to make good decisions in the long-term.
[1] https://raphlinus.github.io/rust/druid/2020/09/25/principled...
This already exists, it is called Free Pascal + Lazarus.
Admittedly, I know nothing about what's actually going on behind the scenes when it comes to graphics + Rust. Just my first impressions as an outsider. I found the existing libraries quite difficult to get started with.
(I'm someone who doesn't know much Rust and is waiting for some of this functionality to mature -- someone already invested in Rust is certainly in a better position to take advantage of the existing graphics support)
[1] https://github.com/MaikKlein/ash/
[2] https://github.com/brendanzab/gl-rsFrom the article:
> One strength is Rust’s wide “dynamic range” – the ability to describe application logic in high level terms while still being attentive to low level details.
So, which text and vector renderer are you proposing? That's not snark, that's a real question.
A GUI that can actually scale requires both a vector rendering engine and a text rendering engine.
On Linux, that's Cairo and Pango--which are Gtk.
I believe that your only other open source vector engine is Skia, from Google.
Am I missing any other options?
I was going to write that there are several, but you already mention most of them. You say though:
"On Linux, that's Cairo and Pango--which are Gtk."
Yeah, they're not really GTK.
Or in any case that's not what people mean when they say they wished a Rust GUI that doesn't use GTK. They mean one that doesn't use GTK+ the lib and widgets, not whether it can use Cairo and Pango...
In 2020 you need HiDPI support, Wayland, and accessibility. You probably also want a toolkit that has a strong developer community. GTK and Qt have these. FLTK is under active development but it is missing a lot modern features. Maybe it will get there by 2022.
The other option, rolling your own, is a ton of work and a quite a bit of "reinventing the wheel". It's certainly possible but it needs a passionate and dedicated team.
Ultimately, I believe our approach will yield higher quality results, but there's a lot to learn from Iced as well.
At the lower level, for some things you really have to integrate deeply with the platform, and for others (text layout is one), there are advantages, including faster builds and smaller binaries. (Ultimately I'd like to have a highly GPU accelerated 2D graphics library that does everything, including text, but that's some ways off and doesn't block current work)
I guess I misunderstood the intent behind the project. I thought it's like a full alternative to GTK / Qt but in Rust which would be really nice to have, but I get that it would be a much bigger project than something built on top of them.
There's a gallery of screenshots here. https://github.com/ocornut/imgui/issues/123
Unlike the others mentioned it is an immediate mode GUI, which is an interesting approach.
There are other options. Maybe unpopular options, but options nonetheless: Electron, and immediate mode GUIs.
They certainly have downsides. But there are "professional" GUI applications in widespread use that are written with both.
Disagree. To be GTK 3/4 are main UI toolkits. If your software manages to look like the rest of my GUIs (read themes, fonts) then I will be happy.
However, if I install your software and it's looking like alien - nah. It's better be looking amazing.
I.e. imagine being able to use this library on something like RedoxOS, not just on Linux. That would fit the idea.
And it's kinda orthogonal to using it on OSes that don't have their own UI layer, because that can be implemented as another backend. For example, wxWidgets wraps native widgets on Win32/macOS/X11 (with Gtk considered "native" for the latter) - but it also has wxUniversal, that renders by itself, and is the backend normally used on platforms like DirectFB.
Exposing a nice, standardized Rust interface would be the purpose. Then you can switch the backend later (for a custom Rust one or something else).
Or do we just enjoy reinventing the wheel?
StyledObject -> View -> Text
StyledObject -> View -> ViewContainer -> Button -> ToggleButton -> MyCustomToggleButton
StyledObject -> View -> ViewContainer -> VerticalLayout -> ListView
But my point is that it's pretty weird to bring up SML in particular around GUI programming. The GUI framework only example I know of is mGTK and SML/tk which are far from idiomatic and pretty much require you to write imperative OOP code in SML. Meanwhile SML has existed for decades. It's one thing to say "people aren't using this great model we've developed the basics off, please help make it better", but if you wanted to write an idiomatic GUI app in SML today, your first step would be to have to write the GUI framework itself because no one else has. They don't provide any real options even if you fully buy in and want to jump in with what they're saying.
But we are not at the 80's anymore, and have more options now. There is very little you can do with OOP that you can't in Rust, and a whole lot of things Rust adds to it. Just because things evolved this way it does not mean they are optimal.
That's so 1991. We're on to GUI's as pure functions of state these days, get on with the program :-)
https://www.freecodecamp.org/news/the-revolution-of-pure-vie...
https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
https://raphlinus.github.io/rust/druid/2020/09/25/principled...
I made the comment because such an abstraction doesn't at all map to reality.
Only if you choose to model your system that way. You can push the same paradigm all the way through: immutable events, and pure functions that transform an event and a previous (immutable) state into a new state.
You’re going to recreate framebuffers and font atlases and invalidate your entire UI every single time? Good joke.
i've never seen that not being called oop
Right, this is textbook interfaces used for composition.
Let me paste you a few paragraphs from the GoF book, released in 1994:
> Inheritance versus Composition
> The two most common techniques for reusing functionality in object-oriented systems are class inheritance and object composition. As we've explained, class inheritance lets you define the implementation of one class in terms of another's. Reuse by subclassing is often referred to as white-box reuse. The term "white-box" refers to visibility: With inheritance, the internals of parent classes are often visible to subclasses.
> Object composition is an alternative to class inheritance. Here, new functionality is obtained by assembling or composing objects to get more complex functionality. Object composition requires that the objects being composed have well-defined interfaces. This style of reuse is called black-box reuse, because no internal details of objects are visible. Objects appear only as "black boxes."
...
> Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system's behavior will depend on their interrelationships instead of being defined in one class.
Like, it's the most well-known OOP design book and it states exactly that - more than a QUARTER CENTURY ago. Who in hell argues that this isn't oop ?!
Maybe widen the bibliography of OOP programming languages beyond Smalltalk and C++ patterns?
Just like placing ECS against OOP, when they are discussed across OOP SIGPLAN papers and are the genesis of language features like Objective-C, CLOS/Flavor protocols and Smalltalk categories.
I guess, as always, the blame lies in how we teach these subjects and many don't do it properly.
Which I consider a better approach than inheritance, ymmv.
There are plenty of ACM and IEEE papers if you want to see it being called OOP.
OOP means that an object which does not exist now can be written in the future, and loaded into code which has already been compiled and is already running now. The method calls in this existing code will correctly resolve to the method implementations in that object.
Components managing their own state is a textbook definition of OOP.
A better approach are mixins. Separate ones for layout and behavior. This is much more flexible, and avoids code duplication or "crazy" inheritance hierarchies at the same time.
Rust Traits are ideal for mixins. So a GUI toolkit in Rust should be just fine.
why does it work fine in Qt then ?
That way any language can do real GUI's, and without screwy bloated buggy JavaScript libraries.
Basically, I find VR mildly interesting, and will put significant effort into it if and when I'm funded for that :)
But AR has significant serious applications!
I could imagine that there are quite some overlaps when it comes to parts of the core technology though, for example regarding VR / AR GUIs.
Join the discord channel https://discord.gg/xENF5Uh
I also think targeting only desktop will avoid so much distraction that comes with targeting iOS and Android
If I just need a canvas to draw into I use the SDL, not GTK or Qt.
I think it might have been Zoom a couple years ago. If I install a desktop application that isn't some command line utility, it's a big deal, like a new girlfriend, feels like a committment. It better be a real appliance that actually requires access to hardware and would need to stay open most of the day.
I struggle to think of the audience for these kinds of concerns about "desktop GUI". If the customer is enterprise, government, etc., then they will want WinForms/C# or Java/Swing and you simply don't get to pick Rust, Go, etc.
If you just need a user interface, GUI nowadays means web or mobile (ideally SwiftUI).
Let's face it, in 10 years, there aren't going to be many people using desktops. The people that will be using desktops (like me) probably will be fine with and prefer curses interfaces that run in a terminal emulator. There you go, that's your cross-platform GUI.
Desktops/laptops are alive and well and there is nothing on the horizon that replaces them.