Rust 2020: GUI and Community
raphlinus.github.io
raphlinus.github.io
Definitely raising the bar
It’s probably the fastest web interface I had ever seen for a phone.
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.
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?
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.
we sure as hell haven't been using the same WPF apps
Well, there are obviously plenty of people who are fairly happy with Qt and Flutter
e.g. Text, HStack, VStack, ZStack, List, ForEach, Button(action, label)
Even if they don't output the same widgets on all OSes, I think just having a shared convention might be a good first step towards learn-once/write-native-everywhere crossplatform UI.
That would kinda suck for everyone who's used to wpf, qt, swing, gtk+, etc, bootstrap, whatever came before wpf, (winforms? Don't remember) etc etc. "Just copy whatever Apple does" seems like the worst possible solution for a cross platform widget naming convention out of many possible bad solutions.
Naming stuff matters a lot less, (but still sucks) but if you pick UI system and copy all its primatives, you're guaranteed to end up with a bunch of widgets that really, really suck in several native widget sets.
Ultimately, there's not a good way to do cross platform UI. It's always going to either be mediocre on all platforms, or really bad on every platform except one. At best, it will be ok for a while, and then one platform will redefine what "native" looks like and now all of the tradeoffs you've made so that it's mostly ok are just technical debt.
I don't mean to piss on anyone's parade, but cross platform UI is probably the hardest problem in software engineering. There have been a dozen or so teams of people smarter than us who have tried and failed.
If it were my job to make a cross platform UI system for rust, I'd quit and get a job where I wasn't set up to fail. If there was a gun to my head, I'd write a fairly thin wrapper around Qt. The idea being that most people already have 1-3 Qt programs they use regularly. So even though it looks like a Qt application instead of a native one they'd still be familiar with it and it wouldn't look out of place. Then I'd spend most of my time engaged in politics. Install a few developers to developed Qt whose job it is ostensibly to be good Qt developer citizens, but whose actual job is to guide the next major version of Qt (which will break stuff) into breaking as little of my stuff as possible.
The second worst (but still bad) way to make a native cross platform UI is to give up, and make a not UI but close to UI cross platform abstraction layer, and then do the half dozen abstraction layer to native UI things separately. That still sucks more than the arena football league though.
No one's ever really done this, so it definitely sucks more than I think it does. But I walked into that suggestion knowing it sucks, so I don't feel bad. I dunno man. Everything about cross platform UI sucks.
The suggestion wasn't about copying whatever Apple does.
It's that SwiftUI has the most simple syntax (that I've seen.)
ZStack() {
Rectangle()
.foregroundColor(.unicornPuke)
VStack() {
Text("Hello")
Text("World")
}
}
But how is that the "worst possible solution?" What OS-specific bias do you see in that?
So maybe the specific constructs for specifying view modifiers and enums could be slightly different for each language, or the ()s might be []s, and maybe we could do away with the {}s.
It would just be a model for describing the UI, that a hypothetical engine backend might take and spit out OS-native widgets. For another OS, you'd plug in a different engine.
At least at first glance it seems to me like if I'm avoiding native OS toolkits, I might as well just target the browser anyway -- or is there something I'm missing?
Windows and OS-X tend to be the more straightforward cases. There is a standard set of UI components which users expect. Things are murkier in the Unix world, with multiple libraries and display technologies.
The alternative of custom painting everything tends to come with more difficult to fix issues however. AWT's successor Swing struggled with things like respecting system user preferences and accessibility. You can find some old Java 1.5 write ups about it: https://web.mit.edu/java_v1.5.0_22/distrib/share/docs/guide/...
https://github.com/kenz-gelsoft/wxRust
As they mention, this is based on a C wrapper round wxWidgets' native C++ API, originally developed to aid in developing a Haskell binding to wxWidgets:
The Rust binding is probably bitrotted for modern Rust, but since it's mostly generated, generating a low-level API using bindgen, which is actively maintained, and then a high-level API using a Python script of its own, it might be fairly easy to resurrect.
bindgen has got pretty good at converting C++ APIs, so it might be worth trying it on wxWidgets' native API, too.
I have no plans to write a GUI application in Rust myself, but i would love for there to be a good option for other people to write native GUI apps in Rust. As many other commenters have noted, cross-platform synthetic GUIs never look or behave quite right.
Personally I'd love to have something like
import SwiftUI // For controls that are common to all OSes
import SwiftUI.Windows // For OS specific featuresIt's hard to imagine that happening. None of these companies have an interest in making it easier to port code away from their platform.
I mean even now Apple has an increased focus on services that must be accessible from everywhere: Music, TV, iCloud Drive. Surely there must be someone there who wishes they had to write most code only once for all OSes without making their app a hog.
I'd settle for just a convention; i.e. let C# remain the primary language on Windows, but introduce SwiftUI-like primitives like Text, HStack, ForEach etc.
The first hit brought me to "Host a custom UWP control in a WPF app using XAML Islands" so there seems to be a distinction (and it implies WPF isn't the star anymore?)
[0] [1] that I could find after a couple searches look way more complex than what the equivalent SwiftUI would be.
<Button x:Name="button" Content="Hello, world!" HorizontalAlignment="Left" Margin = "152,293,0,0" VerticalAlignment="Top"/>
Button(action: play) {
Text("Hello, world!") // Don't need alignment etc. to produce identical output.
}
> If you need to embed any Unicode characters into the text, you can use the standard XML syntax. For example, to put the greeting in smart quotes, use: <Label Text="“Hello, XAML!”" />
I suggested emulating SwiftUI's syntax because it seems to be the most succinct.
[0] https://github.com/microsoft/Windows-appsample-photo-lab/blo...
[1] https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...
[2] https://docs.microsoft.com/en-us/xamarin/xamarin-forms/xaml/...
You can also do it in pure .NET code without XML, hence why I specifically mentioned code first.
So to pick on your example,
var btn = new Button
{
Name = "Button",
Content = "Hello, world!",
HorizontalAlignment = HorizontalAlignment.Left,
};
btn.Click += (s, e) =>
{
// handle click event
};
WinUI is the latest tech, just UWP as usual, still the future of Windows UI, now re-architected not to depend on a specific Windows 10 release, going back all the way to Falls Creator.
I haven't touched C# in ages but that definitely looks odd compared to what I remember of it (like SwiftUI looks a little odd compared to Swift but not by this much.) My immediate thought: why capitalize the property names?
Fabulous is comparatively verbose too but probably more idiomatic with F# (which I have no experience with.)
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.
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.
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.
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.
It's come a long way from the Swing days and I think the biggest issue is it's perceived history, Java / Swing being slow and ugly. The other issues is the lack of marketing of what modern JavaFX can do.
So I wouldn't call it a failure, it's plodded on in the background improving slowly over time, where it has failed is on market adoption.
- I wanted to create a grid of img like elements(something a bit more complex where you have some small buttons on each image), I hit the issue that the browser would take like 2 seconds to load 1000 elements, in a decent GUI toolit this is not a problem, as an example in Flex4 I can have a list with 1000 elements, if only 10 elements are visible then the toolkit creates say 16 GUI elements, as you scroll the elements that get out of view are recycled , in Web you either create all 1000 GUI elements(that each element is maybe formed with a giant div soup) or you use a infinte scrolling like pattern, check Youtube as an example, go to a specific channel video list, you see only 2- 3 rows of videos, then you scroll and wait for next few rows, scroll and wait again, scroll and wait again ...tldr web GUI performance is really bad
- native components are limited, you can't css properly and consistently a numeric input(you can't css the colors of arrows to fit your styles) , you can't have a dropdown that contains icons or some more complex thing like a "Font Families dropdown" , you can't customize the dropdown scrollbar colors so you are forced (is not my fault that desingers want shit to match in theme and not have white crap on a dark theme) to find or create custom components, so you get to import JS libraries and most of the time this components are broken, Ex check the youtube search dropdown, it happened a few time for me to get the dropdown in the search to get stuck open, only way to fix it is to reload the page, Google devs can't properly implement a correct dropdown widget. In PayPal their custom input widget to enter money does not support the "Del" key . In a decent widget toolkit you extend the existing widget, you get all the existing functionality and you add your custom features on top in Web you start with DIVs and CSS do a mediocre job and then fix the issues that get reported if you have the time.
All this issues are solved in Qt, Flex or WPF, the components are performant, you can customize without losing basic features, you don't have to research shit like "what library should I use Monday to implement the numeric spinner input" .
CSS/HTML have some pretty significant problems, but this hasn't been true for years. And in any case, 90% of the native apps I use are basically interactive documents anyway. Unless your definition of "non-toy" apps is primarily referring to apps like Blender or Photoshop, most of the native apps on my computer could be trivially represented in HTML.
You should think of HTML as a render target, not as a document layout framework. HTML isn't where you lay out your application; HTML is where you present your application's data to the user.
> in Web you either create all 1000 GUI elements[...] or you use a infinte scrolling like pattern, check Youtube as an example, go to a specific channel video list, you see only 2- 3 rows of videos, then you scroll and wait for next few rows, scroll and wait again, scroll and wait again
The reason you wait on Youtube is because it's making network requests, not because the HTML is slow to insert. The way you would solve this problem if you weren't worried about network performance would be to use a virtual DOM, because the DOM is a rendering target, not a layout framework.
"Native" controls on the browser do restrict you quite a bit, but that's at least partially on purpose, because the whole point is to use "native" browser conventions with those components. How many times on HN do we see people complaining about scrolljacking on a website? And you want people to be able to style scrollbar colors on top of that? There was significant debate on HN about a month ago about whether it was even a good idea for browsers to respect `autocomplete="off"` in input fields. A significant chunk of your users do not want you to do this kind of stuff.
What the web does do is that it provides you mechanisms to avoid the native components if you have a really, really pressing need to do so -- while encouraging you that most of the time, using built-in browser behaviors will be better for both you and the user.
If Twitter was using native components and not hijacking browser behavior, text input wouldn't insert extra spaces whenever you copy-pasted. If PayPal was using a regular numeric input instead of some custom-built monstrosity, it would respect the delete key and render more consistently with your browser theme. If Youtube wasn't forcing itself to be a single-page app, you wouldn't get bugs where videos failed to load on navigation.
Seeking pixel-level control over every element is the opposite of how you get applications that look and feel native. Looking and feeling native means respecting platform settings and conventions.
About the scrollbars, I am not taling about a document side scrollbar, think at an example of a dropdown with all the font families, those have a scrollbar, I don't want to reimplement the scroll. I want to use the native widgets but the designers decided we will use a dark professional looking theme and the native scroller can't be styled with css, I know the discussions we ahd here on HN about the main page scrollbar and I agree we should use the native widget but we should be able to color it to match the webpage colors , what you will notice in application not webpages is that everyone is using custom component, nobody uses the native dropdowns,scrollbars,calendar, numeric inputs, the reason most of the time is that you are forced into using custom widgets because teh native ones are limited, are not customizable enough.
I 100% agree with you about pixel perfect and styling but I am just a developer, I implemented this weak the numeric input using the native input, I presented it to my boss and they asked me to respect the design, so tomorrow I will have to hunt for a JS library that implements this, look trough it's bug tracking for it's issues etc. I hate I have to do this but6 is not my decision and my initial point is that this is a reason why Web apps are bad as performance or UX , this custom components can run code on your mouse move events, on your clicks, on your scroll events , a native component would be faster and have less bugs and more features.
Visual consistency with the underlying OS is an overblown concern. The application needs to be well-designed and performant.
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.
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.
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 :)
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.
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...