Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

161–170 of 279 posts

Re: Advice for the next dozen Rust GUIs

#161

Post by iovrthoughtthis »

verdagon wrote: post #125
galangalalgol wrote: post #100

Earlier quoted context omitted.

I'm pretty sure the mismatch is just that the major ui frameworks were designed for oop languages, not that UI is inherently oo. As the gp said, react type frameworks play fine with languages that have no inheritance. It's just a matter of a few more coming along with the same paradigm(s).

I suspect the mismatch is actually due to the borrow checker's inability to do various common abstractions such as delegates and observers. These patterns are quite useful, especially in stateful situations such as GUI. They help decouple observer from observable, and can give an architecture more flexibility in a lot of ways. Alas, the borrow checker isn't very amenable to that sort of style.

yup. we need to find a way to manage multiple owned borrows safely

Re: Advice for the next dozen Rust GUIs

#162

Post by malkia »

The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it.

Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around.

Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it - e.g. multi-window support, which might be the stepping stone to these.

Desktop apps are always going to be important in this space. Our game editor (Radiant) relies on this functionality when you use two, three or even more monitors.

Re: Advice for the next dozen Rust GUIs

#163

Post by mjevans »

Nadya wrote: post #51
wmf wrote: post #45

Earlier quoted context omitted.

I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhe…

What's funny is that it pisses off a large number of those 1% of users who swap OSs frequently as well. So it isn't even for the benefit of that 1% either. When operating a Mac I expect Mac-specific behaviors. When operating a Windows PC I expect Windows-specific behaviors. I LOATHE programs that decide to do away with OS-isms that I am accustomed to and require me to learn how to "do things their way" because they w…

Games are the peak of this, since consoles lack anything resembling a filesystem, natural fits for that (like inventory management) tend to differ for every single game... and then they get ported back out to PCs of various flavors with zero adaptation for new peripherals. (Or old ones, as most of those consoles COULD in theory support a keyboard and mouse or touchpad input of some sort too.)

Re: Advice for the next dozen Rust GUIs

#164

Post by kaba0 »

jchw wrote: post #29
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web. And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way. To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is…

The DOM still propagates events upwards, resulting in backwards tree-traversal.

Re: Advice for the next dozen Rust GUIs

#165

Post by int_19h »

msbarnett wrote: post #87
int_19h wrote: post #81

Earlier quoted context omitted.

But this kind of branding wasn't as prevalent before web apps invaded the desktop. Now the users are pretty much conditioned to expect every app to do its own thing.

> But this kind of branding wasn't as prevalent before web apps invaded the desktop. This is ahistorical. App branding now doesn’t hold a candle to the late-90’s mania for every app having its own skin engine. App-vs-platform UI deviation is a lot tamer nowadays.

I remember the late 90s - early 00s very well. I remember that such "branded" apps existed, true. I also remember being annoyed enough at this that I always used equally functional but properly styled alternatives - which is to say, there were such alternatives.

Re: Advice for the next dozen Rust GUIs

#166

Post by kaba0 »

jollybean wrote: post #133
galangalalgol wrote: post #100

Earlier quoted context omitted.

I'm pretty sure the mismatch is just that the major ui frameworks were designed for oop languages, not that UI is inherently oo. As the gp said, react type frameworks play fine with languages that have no inheritance. It's just a matter of a few more coming along with the same paradigm(s).

So that's a good point, but I'm not quite sure OO is the issue. Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for UI because of the overlap between components. I think it's the fact in UI you have a big chunk of state, with references all over, and sometimes doing sort of 'circular references' ... Rust code starts to have a lot of the various Vec Rc Cell Box all over the pl…

> Rust code starts to have a lot of the various Vec Rc Cell Box all over the place

Well, C and C++ also has all of these, with the former having it in a convention-only manner, where you have to learn what the author intended for every project. These are generic paradigms that are useful and often needed for low-level programs, and Rust makes their usage safe.

What I do find problematic regarding rust is that people want to apply it to everything, when it is a low level language, no matter how convenient it can look on the surface. Managed languages are more than fine for the vast majority of problems, they should not be replaced.

Re: Advice for the next dozen Rust GUIs

#168

Post by speedgoose »

liquidnitrogen1 wrote: post #138

Regarding Electron, i don't understand why anyone would want to go this route. I work in finance and desktop native apps (Winforms, WPF) have far more mature libraries, better performance and time to market compared to web GUIs. With Electron, we first write web apps and then wrap inside electron and then reinvent the wheel - this is so stupid.

You only support windows, electron is multiplatform. About time to market it depends on your team. I don’t think there is a big difference between C#/WPF and TypeScript/React. But the second option works on more platforms and you will find competent developers a lot more easily.

Re: Advice for the next dozen Rust GUIs

#169

Post by avgcorrection »

CrimsonVoid wrote: post #40

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (F…

Why would people be annoyed? Plenty of people have done the same thing in this thread. Except they stayed on the GUI topic. So maybe that’s why you included the sheepish intro sentence.

Re: Advice for the next dozen Rust GUIs

#170

Post by PoignardAzur »

malkia wrote: post #162

The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it. Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around. Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it -…

Can you develop?

I understand the term "dockable widgets", but I'm not sure I'm visualizing the same UI as you.

Post reply on HN