
Rust 2020: GUI and Community - justin66
https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.html
======
pfraze
Rik Arends has been working on a cross-platform IDE in Rust called Makepad
[1]. It has a custom UI stack that targets wasm/webGL, osx/metal,
windows/dx11, and linux/opengl. His premise (which is fairly ambitious) is to
work in both 2d and VR environments. It's been fun to watch. There's a demo
for the wasm target. [2]

1\. [https://github.com/makepad/makepad](https://github.com/makepad/makepad)

2\. [https://makepad.github.io/makepad/](https://makepad.github.io/makepad/)

~~~
vsskanth
Other than startup time, the wasm demo is very responsive on an underpowered
moto g7. I'm shocked. Excellent work.

~~~
m0zg
Exactly my thoughts too, except I loaded it on an iMac, and it loaded
instantaneously as well. Far more responsive than any web or Electron UI.

------
saagarjha
The issue I see with a Rust GUI framework that has a target to be native on
multiple platforms is that certain platforms (iOS, macOS) have their toolkits
so tightly bound to a certain language (Objective-C for Cocoa, Swift for
SwiftUI) that it just doesn’t seem feasible to call into it without making
using horrible, hacky, unidiomatic Rust code. I’ve seen projects that aim to
support macOS literally having code like
NSArray(msgSend!(objc::Class(“NSArray”).unwrap(), new)) and it’s just so awful
:(

~~~
raphlinus
Using the widget set provided by the platform is not easy, and that's not what
druid tries to do. Rather, there's a platform abstraction layer (druid-shell)
that takes care of all this stuff for you, and has all that nasty unsafe code
in it, then it draws its own widgets. We _try_ to feel more "native" in that
we're using platform menus and so on. It's certainly possible to be more
native (calling into Cocoa widgets) or less (using Web technology), but I
think what we're doing is a good pragmatic approach.

Of course, things have gotten a bit postmodern, even on macOS there is no
single widget toolkit, but basically a series of choices of what technology to
build on. I'm actually not sure that binding other languages to SwiftUI is
going to work well at all, but in Objective-C it works fine, just isn't very
smooth. On Windows, I've generally found COM to be quite pleasant, and noises
coming from Microsoft suggest that story will become even better.

~~~
saagarjha
> it draws its own widgets

I have never seen this go well in practice :( Qt and Flutter do this and the
experience is just…not great. Do you have any ideas on how to do better than
them if you're using this approach?

~~~
raphlinus
To be clear, we're focusing on the use case of a font editor, where you're
mostly interacting with highly custom views, much less so with layouts
composed of stock widgets.

As I said elsewhere, increasingly we're in a world where there isn't a
standard set of platform UI widgets. I think that was the case when we had
Cocoa on macOS, but on Windows it's a choice between MFC, WinForms, WPF,
WinUI, and those are only some of the choices offered by Microsoft itself.

It's a good question, though. It's possible somebody will figure out a good
way to abstract over officially supported platform UI toolkits, and if so,
that might become a compelling choice. This is one reason why the main point
of my blog is that we need to figure out the best approach, rather than just
assuming we know what to build.

~~~
Macha
MFC and WinForms both just abstractions over Win32. WPF was clearly targeting
being indistinguishable from the old widgets and had a much better success
rate than other reimplementation attempts. It's really only with UWP/WinUI
that you'd notice the difference without going searching and that has received
a lot of consequent complaints.

~~~
jcelerier
> WPF was clearly targeting being indistinguishable from the old widgets

we sure as hell haven't been using the same WPF apps

~~~
Macha
Paint.NET is the one app I've used extensively that I'm aware of being a WPF
app, and that's because I remember reading a dev blog about implementing aero
glass when 4.0 was being developed.

------
traverseda
I'd love to see more mainstream discussion about what gui approaches we could
take.

Personally I'd like to see something like IMGUI but with more of a focus on
data structures, you should be able to cache the result of a function much
more easily.

I guess I'm asking for a more functional-programming styled API for IMGUI.
Allow me to get the benefit of a retained GUI by caching the results of
functions.

At least for the few small toys I've made I think IMGUI is by far the easiest
GUI paradigm to work with. I don't know how it would handle something more
complicated though.

~~~
raphlinus
I also would love to see more discussion of this topic. There are some
academic papers on functional reactive programming and so on, but now there's
this huge wave of frameworks for declarative UI. I've found that there's a
strong convergence on goals (one-way data binding, unification of initial
creation and deltas, etc), but huge diversity in the way they're implemented.

And I also agree that IMGUI is one of the most interesting of these, mostly
because it's very simple. You'll find makepad (mentioned in my blog post and
in comments here) is fairly directly based on IMGUI ideas, but also has the
ability to retain intermediate results. Also, I've been admiring the
architecture of Jetpack Compose, and feel it's true to the ideals of IMGUI -
you can think of it as IMGUI + "positional memoization."

And yeah, it's one thing to build toys and another to build real applications.
This is one reason the focus of druid is to build a font editor, as opposed to
making a GUI toolkit first and hoping for adoption.

------
quantummkv
Honestly, writing a cross platform gui is a waste of time. Java tried
it(multiple times) and failed. Electron tried it and the results are terrible.
Qt is moderately successful at it mostly because it is treated as the system
toolkit on a lot of Linux platforms and Windows users are conditioned not to
care about consistency and experience because of bad enterprise CRUD apps and
Microsoft's own inconsistent behavior.

What rust should do is focus more on interop with other languages. Write your
critical business logic in Rust and make that cross platform. Then write GUI
in the platforms preferred Library/Language combo that handles all the UI and
makes calls to a cross platform rust binary for grunt business logic
processing.

~~~
hombre_fatal
> Electron tried it and the results are terrible.

I use VSCode, Slack, and Discord every day (and some other Electron apps). The
results are great and better than anything I've seen in the xplat space where
there are always trade-offs.

~~~
quantummkv
Is Electron better than most cross platform alternatives? Yes. Is Electron
better than platform's native tooklit? No. Electron apps are easily
recognizable because they completely stand out from the platform apps (not in
a good way). And there are other concerns that are addressed in the numerous
electron threads on HN so I won't list them here.

------
jarjoura
Looks like Windows will soon be launching a way for Rust to call into their
COM UI API platform.

[https://kennykerr.ca/2019/11/05/rust/](https://kennykerr.ca/2019/11/05/rust/)

~~~
ChrisSD
There is already a way as COM is cross-language by design. However what this
will hopefully do is provide a library that makes it natural and using Rust
idioms. I'm looking forward to it.

~~~
pjmlp
All existing Rust libraries only support a subset of COM capabilities and
deployment scenarios.

------
playa1
Iced looks like it has a lot of potential.

[https://github.com/hecrj/iced](https://github.com/hecrj/iced)

------
phkahler
IMHO any GUI toolkit needs to work with multiple languages. So please dont
make it Rust specific.

~~~
raphlinus
This is an interesting question, and one I did not directly address. One of
the features of Rust is that it's practical to bind it to other languages, so
I think writing a "GUI engine" in Rust that's designed to play scripts in
other languages is feasible.

That said, it's not the main goal of the druid project. There, we're focusing
on writing a real application in Rust. Dealing with language binding issues is
hard, and anything that increases the scope too much puts the project at risk.

So if you want a multi-language GUI toolkit written in Rust, asking me is not
the way to get that, because I'm not going to build that. But if you want to
be part of a community effort to build it, I'd be open to collaboration.

------
AndrewDucker
I'm not sure I want to program my UI.

What I want is to draw it, serialise it to some kind of common markup, and
then have an API for dealing with events, altering properties, etc. Making
sure that API works well with Rust makes sense, but doing the whole thing
programmatically doesn't feel like the right model to me.

~~~
flohofwoe
You should give Dear ImGui (which is mentioned in the article) a try. I was
reluctant myself when I discovered it a couple of years ago, but it is such a
joy to work with and so "obviously" the right thing on a very basic level that
ImGui is now my default choice for writing UI tools (even with the
disadvantage of not having a native look and feel).

It's still possible to put a data layer on top of immediate mode UIs, which
basically turn a data representation into a sequence of function calls. But I
think this would bring event handling back, which defeats the whole idea of an
immediate mode UI :)

------
danielscrubs
"We don’t yet know what to build" \- and continues with the thousands of way a
GUI-framework could be built.

I'm sitting here thinking: is it that important for the user? For a hobby-
project sure, but doesn't developers want to wow customers with really nicely
designed GUI:s because of the simple fact that beauty sells?

I'd argue that if you could find a really, really great GUI-designer (not
developer) to take a crack on just one platform (so as to not make a
Frankensteins monster) it would matter way more than if the architecture was
modern or not.

To put it in another way, developers need a guiding hand with UI-design, not
how to structure their program.

~~~
flohofwoe
I think there are (at least) two fundamentally different ways to create UIs,
suited for two fundamentally different types of UI applications:

Programmer-driven for "tools" (think Photoshop, Maya, IDEs, debuggers), and
artist-driven for "user applications" (think typical mobile applications and
games).

For the first type, "maintainability and functionality" is more important than
"beauty on the surface", and it's also important to give the programmer a
framework which encourages "best practices", so that the result is not an
archetypal "programmer UI".

Only for the second type, "shininess" is more important than everything else,
this includes general aesthetics, colors, animations / transitions, etc...

------
Isomorpheus
Very excited to see where this goes! I'm waiting to see which will mature
faster between this and [https://github.com/revery-
ui/revery](https://github.com/revery-ui/revery)

------
shmerl
Would be nice to add Linux build instructions to Runebender (if it needs any
setup besides simply running cargo).

------
axilmar
Wouldn't a Rust interface to Qt be possible or desired?

~~~
steveklabnik
It sorta exists but is difficult and doesn’t support all of QT yet.

