[HN Gopher] Rust: State of GUI, December 2022
___________________________________________________________________
Rust: State of GUI, December 2022
Author : millyleaves
Score : 188 points
Date : 2022-12-14 03:21 UTC (19 hours ago)
(HTM) web link (kas-gui.github.io)
(TXT) w3m dump (kas-gui.github.io)
| jbk wrote:
| How many of those actually look and behave like native and
| support accessibility correctly?
| nicoburns wrote:
| None yet, but that is being worked on.
| zackbrown wrote:
| This is a core design goal for Pax. https://www.pax-lang.org
|
| Pax composites a layer of native text and form elements on top
| of a canvas drawing layer. This solves accessibility across
| platforms, as well SEO on the Web.
|
| This approach also enables a lean runtime footprint (<100Kb,
| particularly useful when targeting Web) because the runtime
| doesn't need to reinvent text rendering, selection, input, etc.
|
| Still early days -- have made very little noise thus far; it's
| pre-alpha -- but you can see what's cooking at
| https://docs.pax-lang.org/ and https://www.github.com/pax-
| lang/pax
| jbk wrote:
| It does not answer the native styling though...
| zackbrown wrote:
| Pax does solve this, but we're now discussing a different
| problem than element-level look-and-feel or accessibility.
| Three ways you can slice this with Pax, ft. pseudocode:
|
| 1. Conditional templating, like:
| <SomeLayout> if $is_android { //Only
| render the back button for Android <BackButton />
| } /* ... */ </SomeLayout>
|
| 2. Dynamic properties where Rust logic checks for the
| target platform, like: <SomeElement
| some_property={self.get_platform_specific_value()} />
|
| 3. Maintain a separate codebase (or different specific
| components) for each target platform, in the spirit of
| React Native
|
| Or any mix of the above.
| zamadatix wrote:
| Does this actually render a native Android back button to
| the canvas or are you simply saying Pax solves this by
| not restricting the user from making their own solution
| to the problem?
| zackbrown wrote:
| Pax's Android chassis isn't built yet -- but a Pax
| `<Button>` will render an actual native Android button to
| a layer on top of a separate canvas layer where vector
| drawing occurs.
|
| That native Android button will be affine-transformed,
| clipped, and occluded so that the two layers together act
| as a single coherent screen, and the developer can simply
| position / transform / layout that `<Button>` alongside,
| on top of, or underneath virtual / drawn elements as if
| they were on the same canvas.
|
| This "dual layer" approach is already implemented for
| Pax's `<Text>` element on macOS (native SwiftUI `Text`)
| and Web (native `<div>` + HTML text) -- see:
| https://docs.pax-lang.org/intro-example.html
| Strom wrote:
| What even is "native" on Windows? Is it Win32? WinForms? WPF?
| UWP? WinUI? Windows App SDK? There's so many to choose from and
| they all look and behave differently.
| izacus wrote:
| Any of those will do as long as you don't drag in javascript
| crap.
| 323 wrote:
| These days the native GUI for Windows is Electron.
| pjmlp wrote:
| Not quite, WebView2, which has the benefit of not dragging
| Chrome with every single application.
| jbk wrote:
| Many of those are native enough, meaning they inherit the
| style from the desktop (and not just emulate it), do they
| support accessibility and so on.
|
| For example, QtWidgets is native and qml is not. WxWidgets
| is, electron is not.
| pjmlp wrote:
| Win32, WinForms, WPF are as good as it gets, and really the
| only ones that matter.
|
| UWP is deprecated, althought it keeps being the one mostly
| used on Windows 11, as WinUI still isn't up to its game and
| keeps collecting issues across all their repos.
|
| Windows App SDK is not a GUI framework, rather the new
| marketing name for Project Reunion, the porting of UWP
| runtime infrastructure on top of standard COM without
| sandoxing and application identity.
| chronogram wrote:
| Do you know which of those toolkits is used for the new
| Windows 11 Notepad? It's quite a bit more "laggy" to scroll
| in than the old Notepad that's still on the Server edition.
| pjmlp wrote:
| The old notepad was Win32, the new one is WinUI, there
| you have it, how good WinUI is in its current state.
|
| https://www.thurrott.com/windows/windows-11/260092/hands-
| on-...
| Macha wrote:
| The native toolkits, and Qt. Gtk if you're on Linux
| bryanlarsen wrote:
| The native bindings are the first section on the list, and they
| work well. If you're concerned about looking and behaving
| native just use those native bindings.
| tpush wrote:
| Native doesn't really exist on desktops except macOS, but
| accessibility is a good question.
| ogoffart wrote:
| With Slint [https://slint-ui.com], our aim is to achieve native
| look and feel, and accessibility.
| cultofmetatron wrote:
| I for one would love to see a toolkit akin to the user interface
| in blender. It would be a boon to anyone building 3d applications
| where high performance is necessary. (the kind of thing you'd
| probably want to use rust for anyway.)
| eklavya wrote:
| Flutter app with rust core works great too.
| satvikpendem wrote:
| Yep, to be honest I don't think Rust has the manpower that
| Flutter has when it comes to writing a fully cross platform
| GUI. I simply don't expect anyone to be able to match Flutter
| or other similar frameworks like Qt without spending a lot of
| time and a lot of money.
| fschuett wrote:
| One day I'll get around to finish my library Azul [1]. Hopefully.
|
| [1] https://azul.rs/
| intelVISA wrote:
| Is there a decent immediate mode GUI for Rust? Think ImGui, I
| know of eGui but unsure how workable it actually is in reality.
| rollcat wrote:
| I've only had a very brief encounter with eGui (using
| Python+ImGui on a project), but I was very positively impressed
| by it. If we were starting that project today, we would've gone
| with eGui.
| phkahler wrote:
| KAS will never be popular so long as it can only be used with
| Rust apps. It's still nice to see how Rust can be used in this
| context, but maybe make it into a wrapper for something more
| flexible.
| Strom wrote:
| This seems like a bad take on popularity. What exactly is the
| criteria here? Is Qt not popular because it's not a JavaScript
| framework?
|
| I think it's much more valuable to look at this from the
| viewpoint of the Rust GUI ecosystem, and not compare absolute
| numbers where nothing comes close to JavaScript .
| phneutral26 wrote:
| wow, really impressive!
| anakaine wrote:
| An impressive write up and understanding of the available
| ecosystem and the way various things stack.
|
| Conversely, an appalling advertisement for the state of GUIs
| with Rust.
| exDM69 wrote:
| More like the state of portable GUI in general, regardless of
| the programming language.
| the__alchemist wrote:
| Of the UI toolkits listed, it seems like Egui is nicest to use.
| It's flexible, has a nice collection of built-in widgets, is
| compatible with 3D graphics APIs (like WGPU), and has a clean
| API.
| smasher164 wrote:
| One thing I'd like to see are Rust bindings for wxWidgets.
| Contrary to the prevailing opinion, I think wrappers over native
| toolkits are a fine approach for cross-platform development.
| smasher164 wrote:
| It looks like the author of wxRust is attempting another go at
| bindings with https://github.com/kenz-gelsoft/wxRust2.
| zackbrown wrote:
| > Contrary to the prevailing opinion
|
| I'm not sure this is the prevailing opinion. It may be
| something of a "vocal minority" opinion, but it does seem more
| common in the Rust community than elsewhere. The closer you get
| to traditional native app designers and developers, the more
| you'll hear the opinion that native look & feel (not to mention
| accessibility) is important to embrace.
|
| IMO an ideal solution is to offer both: 1. to wrap native
| toolkits for things like text and UI controls, and 2. to enable
| canvas-drawn virtual controls, for those who would prefer to
| create their own widgets. These approaches can be enabled in
| parallel through an extensible widget/component system.
| api wrote:
| Take wxWidgets and wrap or modify it to implement a reactive
| programming model. No need to reinvent the lower levels and
| wrappers around native widgets are better for many use cases.
| nu11ptr wrote:
| I think after years of agreeing with you I might actually
| disagree in 2022. I also prefer native widgets, but the problem
| is native programs have changed. It used to be they all looked
| very sterile and had 80-90% of the same widgets as every other
| OS, but if you look at apps today they are all much more media
| centric. Whether electron or native it is very common to have
| things like a "side bar" and other very specific widgets. These
| don't translate well to cross platform native widgets. I think
| Flutter might have the right approach with its fluent UI and
| macos libraries. I suspect the resulting app would look much
| more native in this day and age.
| smasher164 wrote:
| I agree that GUIs have gotten more complicated nowadays, but
| I don't think the existence of platform-specific APIs is
| mutually exclusive with cross-platform abstractions. If
| anything, you should be able to specialize behavior for a
| certain platform.
| pizza234 wrote:
| There are pros and cons to the non-/native approaches.
|
| Writing effective cross-platform application is harder than one
| would think. Some time ago there was a discussion on HN where a
| WxWidgets maintainer stepped in to explain why some WxWidget
| programs were apparently inconsistent across O/S, and the
| explanation was that they were developed naively (I think one
| needs to use specific spacing abstractions, but I don't
| remember with exactness).
|
| For my personal development, I use non-native (which is easier
| to develop), however, on large scale, it'd be a tough decision.
|
| WxWidget was my favorite in the past (again, for personal
| development), however, the bindings are very spotty, which
| prevents adoption for several languages (wiki page: https://en.
| wikipedia.org/wiki/List_of_language_bindings_for_...).
| dohdhdaa wrote:
| Unless a Rust OS is created with an official toolkit, Rust apps
| will always exist on a platform that already has a native
| toolkit. Any custom framework will always feel wrong and out of
| place.
|
| I use macOS, so apps should be written with AppKit. For Linux
| they should either be GTK or Qt, depending on desktop. Recreating
| widgets from scratch with GPU rendering is doomed to feel wrong
| to users.
| oDot wrote:
| Some apps have their own unique look and that works quite well.
| Doesn't feel out of place for me.
| d12bb wrote:
| Depends. Highly specialized apps (Blender comes to mind) fare
| better using custom toolkits. Anything else probably should
| use the platform-native one, not only for looks (lots of
| really great mac-only apps use customized widgets, see Things
| as example), but feel and integration as well.
| mroche wrote:
| I feel like it's a spectrum. The simpler the app, the more
| likely it's better to try an integrate with a closer to
| native look. I always found the issue of "native" to be a
| bit funny to me as someone coming from the 3D/VFX space,
| since all of the applications are built to be multiplatform
| and don't give a hoot about "native". Consistency of the
| application experience across platforms trumps all. The
| number of people I've seen complain about this? Zero.
| Usually the only issues arise around file pickers (some
| have custom ones, others use platform ones which have
| differences).
|
| Granted these applications boast a ridiculous amount of
| features and are incredibly complex putting them on the
| opposite end of the spectrum compared to simple GUIs and
| chat/productivity applications.
|
| To me, it's nice that platforms provide native toolkits* to
| provide this level of integration. But I don't view any app
| as "native" unless it comes from the party making the
| platform, as they are really the only ones that actually
| have to adhere to their human interface guidelines to the
| fullest extent.
|
| * On Linux this is more up-in-the-air. I personally don't
| consider GTK and Qt as native toolkits, but the
| foundational pairing for things like libadwaita and KDE
| Frameworks which provide the associated platform widgets
| and HIG. Using the toolkits directly is fine and will
| mostly work, but it's not the same as a "native"
| application.
| rcarr wrote:
| There's this:
|
| https://www.redox-os.org
| bobajeff wrote:
| It seems to me Mac users care about using native UI toolkits
| more so than Linux or even Windows users. I would suppose that
| has to do with how polished and integrated that platform is.
|
| As a Linux user I really don't care if you use GTK for the UI.
| I've long given up on customizing the look and feel of my
| system to the point that application integration matter.
| drkhn1234 wrote:
| troad wrote:
| For many decades, there have existed commercial apps native
| to the Apple ecosystem, often from small/mid-sized studios,
| which would use native UI to signal their premium
| craftsmanship. I think that for many long-time Mac users,
| seamless/native UI is still a signal of quality in third-
| party software. However, this sentiment is moribund. That
| entire market is now dwarfed by the ecosystem of "cross-
| platform apps" (formerly Windows ports, now usually web apps)
| and Unixy OSS tools; all the while the Mac App Store now
| peddles lots of native-UI apps of deeply questionable
| quality.
| mistrial9 wrote:
| long ago, the integrated feeling of Apple MacOS was a great
| selling point; decades later, daily use of the web, more
| phone than desktop, Windows low-bar junk and other factors
| change the equation.
|
| If a smart user here today says that recent network-centric
| apps are OK with him visually, then maybe they are OK?
| twoodfin wrote:
| I think Apple made a strategic error when they failed to
| embrace DOM/browser engine-based toolkits like Electron on
| the Mac. If they had applied their leverage, of which they
| have plenty, the technical challenges of better native
| integration and support for the wide range of traditional
| Mac affordances would seem to have been quite manageable.
| rollcat wrote:
| There's some reason to your proposition. Directly
| integrating/"embracing" foreign toolkits/web engines is
| the last thing Apple would ever do, but exposing more of
| the underlying machinery to allow third parties to
| integrate better - yeah, sounds good.
|
| On the topic of Rust GUIs on Mac, this was recently in
| the news:
|
| https://github.com/emilk/egui/commit/e1f348e4b24c2fa83d25
| c6a...
| bitexploder wrote:
| The only cross platform toolkit that pulls it off well is Java.
| IntelliJ feels good on every platform. Qt apps can also feel
| native if a little effort is put into it. Rust GUI frameworks
| are one of its weaker areas IMO.
| thiht wrote:
| When it comes to Java GUIs, Intellij is the exception, not
| the rule.
| bitexploder wrote:
| Ahh, well, it is the only one I use so, just a slight bias
| there :-D
| ptx wrote:
| The next time you use a Swing app, look for these examples of
| how it "pulls it off well":
|
| * The first time any particular window is opened, Swing draws
| the contents but then changes its mind about the window size,
| recalculates the layout and then redraws the contents again
| slightly differently.
|
| * When Swing creates a window, you can sometimes observe how
| creates it in the wrong spot and then moves it to where it
| was supposed to be created.
|
| * Alt-tabbing quickly between two windows in a Swing
| application doesn't always work. It sometimes just glitches
| and leaves you in the window you started with. (Confirmed
| just now on Windows 10 with Java 17. The bug has been there
| for many, many years.)
|
| * When opening a submenu of a menu, Swing does nothing to
| handle the problem of the menu closing again as you're moving
| towards it but accidentally mouse over an adjacent item.
| Platform GUI toolkits solve this either with a delay or by
| tracking the direction of the movement. IntelliJ implements
| its own menu bar to make this work.
|
| * Try to find an example of a window that is resizable in
| only one direction or only up to a certain maximum size. As
| far as I can tell, this is not possible in Swing, and
| applications handle this limitation by designing all UIs to
| be resizable even when it doesn't make any sense.
| amatheus wrote:
| Regarding Java I think that's more of a Jetbrains thing that
| IntelliJ feels good on every platform than Java per se.
| Contrast it with Netbeans for a more "pure" Java desktop
| experience.
| cmrdporcupine wrote:
| I've been an JetBrains (IntelliJ and these days CLion) user
| since about 2004 and what I'd say is this was a hard fought
| and slow incremental advancement. Back in the 00s, IDEA's
| UI experience was really sub-par and its foreign nature on
| the platform was very very clear.
|
| It's amazing the amount of work JetBrains has put into
| this.
| chrismorgan wrote:
| I have never had anything other than a terrible experience
| with a Java app, under Windows, Linux (in GNOME 2 and Unity
| most of a decade ago, i3, or Sway). They always disregard
| platform conventions in both look and feel to a painful
| extent. But I will declare that I haven't ever used IntelliJ,
| and I have no idea what it uses for its UI. But out of the
| box, Qt seems vastly better at matching platform look and
| feel, and generally gives you decent control over matching or
| not to match your requirements.
| josephg wrote:
| I use intellij on Linux and macos.
|
| It looks mostly ok, but on Linux it doesn't support smooth
| scrolling (even though this is supported by gtk). You also
| can't use the meta key (windows key / cmd) as a modifier
| key for keyboard shortcuts. So I can't configure intellij
| to use all the keyboard bindings I'm used to from macos.
| Again, this isn't a problem with other gtk apps. It's just
| (apparently) a platform limitation of whatever Java toolkit
| they're using.
|
| So in my experience it's 95% of the way there. I certainly
| prefer it over Xcode, but it has issues that native apps
| don't have.
| silon42 wrote:
| SWT was pretty good in my experience.
| ptx wrote:
| SWT is even better now.
|
| First of all, up-to-date official packages are now
| published to Maven Central as part of the release
| process, so you can just add it as a dependency as easily
| as with any other library. Until recently you would have
| had to either fiddle around with Eclipse's alternative
| package management system, download it manually or use
| someone's unofficial Maven artifact. But that's now
| resolved.
|
| Secondly, if you bundle a Java runtime customized with
| jlink (as is recommended these days), an SWT application
| is actually smaller than a Swing application. When you
| don't use Swing, you can exclude the entire
| "java.desktop" module, which is slightly larger than the
| SWT libraries.
| bryanlarsen wrote:
| The _first_ item on the list is cacao, the rust bindings for
| AppKit. And that is IMO the best option for building MacOS apps
| in rust.
| meindnoch wrote:
| This. It's so lame when UI elements can't hang outside the
| bounds of the window (i.e. menus, tooltips, dropdowns,
| popovers) because everything is rendered like a game...
| nicoburns wrote:
| There's no reason Rust toolkits can't use separate windows
| for elements like menus and tooltips, and I know this is
| planned for at least some of the toolkits discussed in the
| post.
| Strom wrote:
| What you are talking about has nothing to do with custom vs
| native controls. Instead it's a question of using a single or
| multiple windows.
|
| There are Rust GUI toolkits like Druid with custom controls
| that have elements outside the bounds of the main window.
| virtualritz wrote:
| > Recreating widgets from scratch with GPU rendering is doomed
| to feel wrong to users.
|
| So following your argument, pretty much all apps I use on macOS
| are 'wrong' as far as GUI goes.
|
| Off the top of my head from what I use most of the time: Maya,
| Houdini, Blender, Fusion360, Resolve, Darktable, Slack,
| Discord, VSCode. Not a single one of them uses native Cocoa
| widgets. And I couldn't care less.
|
| Some of these are top of the line apps for 2D/3D content
| creation on that platform.
|
| If the vendors of these apps can afford to not care about UI
| nativeness, why should any single one or small group of
| developers working their asses off on GUI crates for Rust?
| Mostly unpaid no less.
| rollcat wrote:
| > Not a single one of them uses native Cocoa widgets. And I
| couldn't care less.
|
| Meanwhile I do care. My main reason being: macOS offers
| fantastic facilities for inspecting and scripting the native
| GUIs, think using the web inspector or GreaseMonkey, but
| across the entire OS - but of course it breaks e.g. on
| Electron apps. Other people will cite help menu integration,
| custom key shortcuts, accessibility (not only for the
| disabled), and - yes, resource usage. I remember being
| productive on a system with 256M of RAM, and before that -
| 4M, and before that - 64k. It's frustrating to see so much
| progress wasted, I shouldn't need to close ALL of the chat
| apps just to run StableDiffusion more smoothly.
| smoldesu wrote:
| Maybe Apple should write libraries for their GUI toolkits,
| then. It's awfully hard to beg people to write native apps
| for you when people need to learn a new language to do it.
| worik wrote:
| And when that new language is Swift. Coming from Rust
| Swift is hard to take.
| smoldesu wrote:
| That's more-or-less what I'm getting at. Apple can't
| replace Objective-C with Swift and expect people to not
| cock their head. They can either support a pre-existing
| language (like Microsoft with Rust) or home-bake
| something suitable for low-level development. Telling
| developers to not use the stuff they want to use sorta
| leaves their hands tied.
| lelanthran wrote:
| > So following your argument, pretty much all apps I use on
| macOS are 'wrong' as far as GUI goes.
|
| MacOS apps feel pretty wrong to me.
|
| Some don't remember which screen they should be on, and
| always go to that screen at a predetermined size and geometry
| (tkdiff).
|
| Others expand incorrectly to full-screen (macvim) when moved
| to a different screen.
|
| VSCode doesn't behave like the native apps.
|
| The list goes on, I'm short on time.
|
| > And I couldn't care less.
|
| You caring or not doesn't make the problem go away - native
| widgets always feel less wrong than non-native widgets.
| virtualritz wrote:
| My main counter argument would be that most of the tasks I
| do on macOS require/are better done full screen.
|
| And if you are on macOS doing any kind of design work, this
| is your mode of working. People using Photoshop or any
| 2D/3D DCC etc. You use all the screen space real estate on
| any number of screens you have. But even if I write code I
| run VSCode in full screen. If I have a dual screen setup I
| usually have one screen with two code editors, mini map &
| folders + terminal on screen two. But that's it.
|
| But even assuming you run apps side by side/stacked
| whatever so you could actually visually see how non-
| native/different they look. Is that the real issue on macOS
| today? Personally the main gripe I have is that -- and
| kindly pardon the tangent -- macOS native window management
| is shite. One of the first things people that come from a
| *nix desktop buy/install, when they switch to macOS, is a
| proper (possibly tiling) window manager.
|
| But back to widgets/look: in DCC apps the main sort of
| dialog you interact with are attribute editors where you
| change properties of an object or node.
|
| I like to refer to an issue on the egui crate which has
| some of the best out-of-the-box support for this kind of
| widget composition[1].
|
| Apple Human Interface (AHI) guidelines do not have any
| handrails on how these attribute editors should look or be
| done. The best you can do is go with dialog AHI guidelines
| and these fall short for this sort of window. I can go into
| great detail here why but it's beside the point. If you
| read my comment on the egui issue I linked above (same
| handle I use on HN) you may get an idea where I am coming
| from.
|
| Most Human Computer Interface (HCI) guidlines for various
| platforms are based on typical late 90's early 2k desktop
| apps.
|
| They were never updated to reflect on newer paradigmns for
| UX that evolved in recent years. Blame the fragmentation of
| the desktop and Electron & co.
|
| IMHO this is the first problem the OS vendors need to solve
| before we can blame developers of UI libs to not make them
| look 'native enough'.
|
| [1] https://github.com/emilk/egui/issues/88
| homarp wrote:
| >newer paradigmns for UX that evolved in recent years.
|
| can you provide some examples on desktop? Touch maybe,
| but that is not used on desktop, afaik.
| virtualritz wrote:
| I should probably have said patterns, not paradignms but
| this beside the point.
|
| I mean stuff that is common enough to deserve a defintion
| and a best practice laid out in a human computer
| interface (HCI) guideline document for a platform/OS.
|
| Off the top of my head:
|
| Tab closing behaviour on Chrome/FF. Close a tab, other
| tabs shift but don't change size immediately so you the
| next tab's close button is directly under the mouse and
| can bel clicked to close another tab (and another, and
| ...).
|
| Another one: the typical chat app with
| servers/groups/contacts on a list on the left and the
| chat on the right (and possibly threads on the far
| right).
|
| There is no good standard for this, everyone cooks their
| own soup so stuff you learned for Slack doesn't apply in
| Discord etc. I.e. it's a pattern of some sort but there
| are no Windows/macOS/Qt/GTK interface guidelines covering
| this case and/or suggesting best practices. This includes
| e.g. platform standard keybindings to select stuff in
| such apps (at best Tab switching works).
|
| Another one is use of (some) Markdown-inspired stuff in
| chat apps. I.e. `monospaced` ```monospaced multline``` or
| even ```<language for syntax highlighting> ...```.
|
| In Slack ``` works but ```<lang> doesn not (but does in
| Discord, used to work in Slack in the past, I think).
|
| I think there are many such patterns that are maybe not
| as groundbreaking than the invention of tabs (90's?),
| combo boxes/menus (also 90's? When there are too many
| choices for radio buttons) etc.
|
| But beause they are used in some form (or another,
| unfortunately) by many apps now, the OS vendors should
| define a best practice for implementing their end-user
| facing functionality/behavior in their HCI guidelines.
|
| Even if the platform itself doesn't provide a ready-made
| widget for each such case.
|
| Hope that makes sense and explains what I meant.
| zamadatix wrote:
| On that tangent what are the top alternative window
| managers people here use on macOS? The native window
| management does indeed drive me up the wall.
| hollerith wrote:
| >Maya, Houdini, Blender, Fusion360, Resolve, Darktable,
| Slack, Discord, VSCode. Not a single one of them uses native
| Cocoa widgets.
|
| Also Firefox and Chrome and their forks (e.g., Brave).
| ruph123 wrote:
| You can write GTK applications in Rust:
| https://www.gtk.org/docs/language-bindings/rust/
| dpcx wrote:
| You can, but its documentation is (was?) a horrid mess of C
| examples that make it quite difficult to navigate.
| jeroenhd wrote:
| This was my experience as well. Simple windows with a
| button that increments a number are nice and understandable
| but if you try to get more complex controls working, you
| run into docs.
|
| With C code often being unreadable, I found that Vala
| applications often have readable examples of how to use UI
| components. However, tooling support for Vala is extremely
| limited so experimenting with existing code may be a
| annoying. That said, I've had good experiences with opening
| these projects in Gnome Builder (once it got updated to
| work on my computer again).
|
| If your component of choice doesn't have a Vala example,
| I'd resort to reading the documentation. Reverse
| engineering the API from the docs is often quite doable if
| you first look at how a component you do understand.
|
| I've had similar problems, but worse, when I tried mixing
| Rust and Qt. I've never used Qt before so that doesn't
| help, but I found the API even less predictable in many
| cases, with some docs and examples several versions out of
| date.
|
| I'd seriously consider just shipping a WINE'd Windows
| binary (using a tool like https://winepak.github.io/) for
| Linux targets with the current state of Rust GUI platforms.
| The amount of game UI/custom UI libraries out there is
| impressive but they all feel terribly wrong when I try to
| use them, in the same way most Flutter apps are terrible to
| use on desktop.
| pg999w wrote:
| There are plenty of apps written with Electron, which has
| styles far from "native" UI. But most people should not think
| of them as wrong.
| nicoburns wrote:
| > Unless a Rust OS is created with an official toolkit, Rust
| apps will always exist on a platform that already has a native
| toolkit.
|
| If the toolkit is good enough it's entirely possible that a
| platform or platforms may adopt it as their native toolkit. In
| any case, these are really competing with electron which is
| already non-native. If Rust toolkits can get to electron-like
| quality but with lower resource usage and better hooks into the
| underlying platform then I'd consider that a success.
| pjmlp wrote:
| With exception of VSCode, the only Electron apps that I use
| are forced upon me due to work requirements.
|
| All of them I glady ignore on private owned computers, or use
| the browser version, they are anyway Web apps.
| madeofpalk wrote:
| > In any case, these are really competing with electron which
| is already non-native
|
| Use Electron and you'll get OS-native buttons and other form
| controls.
| Strom wrote:
| Can you provide any source/documentation on how to achieve
| this?
|
| As far as I know Electron is based on Chromium. And
| Chromium doesn't use native controls, it has its own custom
| controls that sometimes look similar to native controls.
| zorr wrote:
| I think, now in 2022 it is time to let go of this idea (for
| cross-platform applications). What you propose means that any
| app that wants to be available on "all" desktop platforms has
| to be written at least 4 times (macOS, Windows, GTK, Qt) and
| few developers or organizations have the resources for that.
|
| > Recreating widgets from scratch with GPU rendering is doomed
| to feel wrong to users.
|
| Yes, and no. When these widgets try to mimic platform-native
| widgets we have the uncanny valley problem which makes
| everything feel out of place like you describe. But if we drop
| this constraint and design widgets with their own consistent
| style within the same app, we don't have this problem. Apps
| like the JetBrains IDE's and Todoist show that this can be
| done.
|
| To me the middle-ground solution is a UI toolkit with its own
| widget style, that has some tie-in with platform-native things
| and conventions like windows, menus, notification trays and
| keyboard shortcuts. Essentially GTK or Qt without the focus on
| pixel-perfect matching of platform-widgets. I think this is
| what Druid is doing. Rust is in a good place for this as it is
| a modern language that works well on all of these platforms,
| with no native UI toolkit yet and a package-manager/build-
| system that supports multi-platform library configuration.
|
| There will always be a place for platform-native apps but
| cross-platform apps have different requirements. I don't care
| that my todo list application or IDE does not look exactly
| "native" on my Macbook. However I do care that these
| applications look and feel similar when I use them on my
| Macbook vs on my Linux machines or Windows laptop. Preferably
| without dragging in a full web-based rendering engine a la
| Electron.
| dmitriid wrote:
| > But if we drop this constraint and design widgets with
| their own consistent style within the same app
|
| Style is just one of many things. And it's extremely hard to
| properly code your own consistent UI toolkit.
|
| On top of that every platform has a myriad of platform-
| specific behaviors that people expect and that you _will_ get
| wrong in yours. Accessibility is the big elephant in the
| room. But even things like secondary focus in prompts
| /dialogs on MacOS (that Apple's own Catalyst and Swift forget
| about) is a bitch and a half to get right.
| zorr wrote:
| I agree, which is why I'm not advocating writing or
| designing your own toolkit. Instead we as a developer
| community should focus on the "next generation" of toolkits
| for the modern cross-platform world. Take all that we have
| learned from GTK, Qt, Flutter and all the web stuff and
| incorporate it into something new for the next 10-20 years.
|
| Rust is a nice language for that since it is already a
| "next-generation" language in terms of memory safety and
| its momentum is still building. Projects like Druid, while
| far from ready, are a good starting point.
| cmrdporcupine wrote:
| The problem with this is unless you drag in something like
| Electron, you're inevitably going to end up using (or
| writing) something that just doesn't have the number of
| maintainers and quality development as either the native UI
| or an embedded webview. There's nothing with the level of
| development of e.g. Qt for Rust.
|
| Which means "unsexy" things like accessibility get left by
| the wayside. And your users suffer.
|
| Writing a UI kit is a huge task. It's one of those things
| (like so much else in our industry) where you can fairly
| quickly climb "stupid mountain" by getting a pile of shiny
| widgets on the screen; but then you look out over the valley
| below and realize that, holy, crap there's a whole other
| mountain range of things that a UI kit has to do.
|
| It's also a tough story for Rust, in particular, because
| copying what other people have done with other toolkits won't
| really cut it. Rust's ownership semantics and general
| opinions don't necessarily accord well with the highly object
| oriented and event-loop / object-tree structure of most
| existing GUI toolkits.
|
| Aside: I still don't understand why things like Electron
| based apps are so bloated. They seem to static link whole
| chunks of their own (forked) Chromium. But both Windows and
| Mac OS ship native webview components as part of their system
| which can be used instead. I've done this myself (used Edge's
| Chromium webview component in a VST synthesizer, and equiv
| webkit stuff on Mac) and binary sizes were entirely
| reasonable. Linux was a slightly more complicated story.
| zorr wrote:
| It's a tough story indeed, but every existing toolkit had
| to start from scratch at some point. If I'm not mistaken
| Druid had its start in 2017 (I personally contributed some
| stuff on the GTK bits around 2019) and it is far from ready
| but I see it progressing in the right direction.
| Accessibility is on its roadmap as well I believe.
|
| This is why Rusts' "Are we GUI yet?" and posts like this
| are a good thing. Eventually some new toolkit will arise
| that ticks all the boxes. We are not there yet and it will
| require a huge amount of work.
| silon42 wrote:
| >For Linux they should either be GTK or Qt, "depending on
| desktop"
|
| That's bad... ideally there should be a runtime choice between
| GTK / Qt.
|
| side note... I know many people that would prefer apps on MacOS
| to behave like Windows/Linux (mostly about the keyboard)... and
| also the reverse (those are louder to complain, but a minority
| in my case).
| aaa_aaa wrote:
| That will probably be Fuchsia, if it lives.
| thiht wrote:
| > Any custom framework will always feel wrong and out of place
|
| Pretty sure that's the wrong metric. Users don't care if the
| interface doesn't look exactly like the rest as long as it's
| good looking and feels familiar.
|
| As a heavy VSCode user for example, I don't think it feels out
| of place on a mac for example. The UI is consistent in itself,
| and the UX is consistent with the global UX of the OS (more so
| than some native mac apps like Finder for instance).
|
| The main reason I hated Java Swing apps was that they were ugly
| as hell, not that they didn't feel native.
| robertkrahn01 wrote:
| https://github.com/gabdube/native-windows-gui isn't in the list
| but is quite a polished option for building Windows specific
| GUIs. Seems to be the more mature option compared to winsafe.
| 323 wrote:
| 10 years ago Python was famous for how many web frameworks it
| had.
|
| It seems Rust will be famous for the number of GUI libraries.
| littlestymaar wrote:
| Oh, but Rust has even more web framework than GUIs libraries;).
| zackbrown wrote:
| Why?
|
| 1. Rust is growing in popularity, and a compelling GUI solution
| is needed
|
| 2. These solutions take significant time to incubate, so many
| of the ones we're seeing emerge have been incubating for months
| or years, started at a time when there were fewer options.
|
| 3. The implications for cross-platform app development with
| Rust are profound, and offer us a way to break free from the
| pain-points and shortcomings of the local maximum solutions du
| jour: Web + Electron and Phonegap-style WebView mobile apps.
| joshka wrote:
| Anyone have a recommendation of what they'd use to run on a
| raspberry pi with a touch screen? My preference would be booting
| direct to the gui and having no other things running (i.e. X11 /
| etc.) as well as having a good development story for macOS. Is
| there something decent that enables this for rust? Bonus points
| for github example repos.
| kevin_thibedeau wrote:
| Qt is the most mature system for running on a framebuffer.
| Lichtso wrote:
| Shameless self promotion plug, I developed a GPU accelerated 2D
| rendering framework in Rust as well. It even comes with an
| experimental UI framework on top, which you can try in the
| browser if you have WebGPU enabled:
|
| https://github.com/Lichtso/contrast_renderer
| terhechte wrote:
| Hey, I just ran the showcase locally. That looks super cool!
| Awesome project!
| Lichtso wrote:
| Thanks!
|
| You can also checkout the "feature/ui" branch in GIT [1] to
| get the UI framework prototype.
|
| [1]:
| https://github.com/Lichtso/contrast_renderer/tree/feature/ui
| worik wrote:
| My favourite GUI is and always will be the command line.
| dfgdfgffd wrote:
| Sadly Rust for WinUI3/UWP/XAML for Windows GUI - actually modern
| UIs on Windows - was abandoned or explicitly removed from Rust
| API bindings by MS.
|
| The listed library only uses the ancient win32 api
| nickpp wrote:
| Any idea why?! I find that the modern WinUI is impossible to
| use from any language other than .NET.
| Santosh83 wrote:
| Perhaps that's the plan?
| withinrafael wrote:
| We yanked it because, sadly, XAML/WinUI is squarely designed
| to be used with C# and Visual Studio.
|
| See also: https://github.com/microsoft/windows-
| rs/issues/2153#issuecom...
| fsloth wrote:
| win32 api is pretty good. I don't see why you would want
| anything else for native app development. If you want to use
| the modern stuff it's far better to develop the UI frontend
| using Microsoft tools in C# and then use Rust as the backend.
| In this sense Rust story is not worse than C++ or C.
|
| If a person wants a native gui I guess QT would be worth
| investigating as well (unless one is concerned by the license).
| zozbot234 wrote:
| Isn't that what the windows-rs crate is for? Doesn't seem
| abandoned.
| yencabulator wrote:
| It sure is abandoned: https://github.com/microsoft/windows-
| app-rs#this-repository-...
| yenhoo wrote:
| Sadly?
|
| I prefer desktop Windows programs to be gdi/win32, they are
| often the most thought out and optimized for actual desktop
| paradigms (i.e mouse+keyboard+high res screen) without giant
| margins, padding and whitespace everywhere and makes use of
| proper desktop class widgets like treeviews, listviews, tabs,
| etc.
| mm007emko wrote:
| Exactly. Haters gonna hate me but I really liked
| Windows.Forms (and C#) for development line-of-business
| desktop apps.
| pjmlp wrote:
| Nah, still quite good, although I personally would go with
| WPF, Forms is also quite good for what still matters on
| Windows desktop, just note that on the new runtime (.NET
| Core) there are still some issues with the out of process
| designer.
| pjmlp wrote:
| Doesn't surprise me, the folks behind it are the same that
| caused the deprecation from C++/CX, the very first time that
| Microsoft had something comparable to C++ Builder in
| productivity for C++ RAD GUI development.
|
| It got replaced with C++/WinRT, which basically requires one to
| code like in the good old days of Visual C++ 6.0 alongside ATL,
| editing IDL files without any kind of VS tooling support and
| manually merging generated code.
|
| Even the eldery MFC has better VS tooling support and COM
| authoring APIs than C++/WinRT.
|
| Rust/WinRT is even years away from the C++/WinRT "productivity"
| in its current state, let along what .NET tooling provides,
| which by the way is also worse than UWP with .NET Native (e.g.
| no designer available, and no AOT support).
|
| The reality is that only WinDev folks actually care enough
| about WinUI, the rest of us have moved on burned by these
| rewrites, and only a few hardcore advocates keep showing up
| their community calls.
| onphonenow wrote:
| Which is a massive bummer because win ui stuff w designer etc
| used to be great and performed better than a lot of electron
| stuff and was easy to develop - but they have seriously
| trashed their ecosystem there
| pjmlp wrote:
| Yeah, if you browse around the public repos, and occasional
| community calls, it really seems that whoever is still
| around has no idea (experience) of what are the features of
| the frameworks they are trying to replace, and asking for
| yet another rewrite on top of all of those done since
| Windows 8 is trivial.
|
| Anyone that is still around beyond WinDev themselves just
| has too much sunk down cost into WinUI to switch for
| something else, even pre-Windows 8 stacks.
| rtpg wrote:
| A pretty fun Rust GUI experienc is vgtk[0], which is doing a
| bunch of macro magic to give a "we're coding in React" vibe to
| GTK+. I don't really have a specific thing I want to code in a
| native GUI at the moment but if I did I think this would be the
| most tempting for me.
|
| [0]: https://github.com/bodil/vgtk/
| fnord123 wrote:
| Relm4 is similar.
|
| https://relm4.org/
| tristan957 wrote:
| FYI the project is called GTK, not GTK+, these days. They
| dropped it late in the 3.X cycle if I remember correctly.
| bryanlarsen wrote:
| Shout out to Dioxus. It's a react clone that provides a really
| nice experience and can run a web GUI faster than React can.
| That's quite the accomplishment given the disadvantage of having
| to use shims to access the DOM.
|
| If you want to choose a single language that can create native
| GUI's, Rust is probably your best or only choice. Other languages
| are lacking a good story for either the web or for iOS but Rust
| works well on both.
| [deleted]
| ink404 wrote:
| kotlin is a decent choice as well
| bryanlarsen wrote:
| True. I forgot about the family of languages that will
| transpile to Javascript. That gives most of them a good web
| front end story, and of course Kotlin has a good iOS story.
| mritchie712 wrote:
| have you built anything with it? We're using Tauri, but Dioxus
| looks very interesting.
| terhechte wrote:
| I recently build this side project with Dioxus:
|
| https://terhechte.github.io/twitvault/
|
| Here's a review of the experience of using it:
|
| https://www.reddit.com/r/rust/comments/zegv2e/comment/izb6nl.
| ..
| ianpurton wrote:
| Can you let me know about incremental compile times?
|
| Basically with the HTML frameworks that use macros I'm
| getting incremental builds 10 seconds or more. Did you
| experience the same?
| terhechte wrote:
| Incremental compile times were quite fast, I'd say in the
| 1-2 seconds. I also have another project where I'm using
| Dioxus-web for a web application. When building a web
| app, it also has hot code reloading and I'd say reloads
| take under a second (though I just started this app so it
| only has a couple hundred lines of code).
|
| I have an M1 Pro Max though, which is quite a fast
| machine.
| anon23anon wrote:
| Does Dioxus run in a webview on mobile? That's how I'm
| reading the docs.
| bryanlarsen wrote:
| In theory it doesn't have to. In practice, yes.
|
| My comment said that rust had a great cross-platform story,
| not Dioxus. If I was doing cross-platform rust I'd use
| cacao for iOS, Dioxus for web front end, et cetera.
| bryanlarsen wrote:
| I have, but nothing used by more than 3 people.
| logicalshift wrote:
| I've been working a 2D rendering toolkit that increasingly looks
| to me like it probably deserves a mention on these lists:
| https://github.com/logicalshift/flo_draw (but I'm not on
| Reddit...). Layers, vector sprites, dynamic textures and a
| streaming API that fits well with 'reactive' designs are amongst
| the features that make it stand out from what else is out there.
| It's super simple to get going too.
|
| Started life as a rendering layer for FlowBetween so I could put
| in whatever looked like it was 'winning' later on but wound up
| writing my own renderer as there wasn't anything quite there yet.
| Still has that design so another unique thing is that it's
| possible to use the same API with whatever rendering layer you
| want.
|
| Speaking of FlowBetween, one thing I have wanted to do for ages
| is to get rid of the platform-specific GUIs and use something
| universal. It _should_ be easy because FlowBetween sends
| straightforward instructions to an independent GUI layer, but I
| keep bouncing off for a few reasons:
|
| - it's a big ole task so I definitely want to pick something
| that's stable and also lets me hedge my bets in terms of being
| easy to migrate away from
|
| - most commonly, FlowBetween needs pressure data from tablets and
| a lot of frameworks just don't do that (this is also in a
| terrible state in browsers)
|
| - lots of GUI crates are designed as frameworks and so try to
| dictate the entire design of any app that uses them, which is no
| good for FlowBetween which tries to keep its internal design
| choices independent of its choice of GUI
|
| At the moment, I suspect that some sort of imgui framework is
| best along with an entirely manual implementation of tablet
| pointer data: fits with my existing design and isn't 'contagious'
| in a way that could make it hard to migrate to something else
| later on.
___________________________________________________________________
(page generated 2022-12-14 23:03 UTC)