Comment by pornel | Hacker News Reader

Comment by pornel | Hacker News Reader

egui's immediate mode works great with Rust's ownership and borrowing, unlike traditional stateful UI frameworks that can have arbitrary references between widgets and events.

It works very well in games, where it allows creation of complex completely custom UIs, with GPU rendering.

However, egui is an odd choice for desktop applications. It's completely non-native. Even "windows" in egui are custom widgets confined to its canvas, not real OS windows.

> However, egui is an odd choice for desktop applications. It's completely non-native.

I happened to immediately (pun intended) stumble with an example of this. Just by chance, I went straight to test the ComboBox (https://www.egui.rs/), and I have the tendency of not just clicking to make the drop-down appear; instead, I click and hold, and only release after selecting the desired choice.

This doesn't work at all on egui: the ComboBox doesn't show its choices until the mouse button is released, not upon the initial mousedown press.

I guess there must be a thousand cuts like this, which is understandable, given that all functionality is implemented from scratch trying to imitate the native widgets we all know and use since forever.

It's also difficult because what is the native behavior here? On Windows the different official Microsoft UI toolkits behave differently. For example the latest Windows 11 UI stuff works like egui in that it opens the dropdown on release, while older GDI stuff opens the dropdown on press, but won't let you make a choice until you release.

After reading this I tried click-and-hold on a folder in the bookmark bar in Chrome. Lo and behold, even Chrome doesn't do what you want. I completely agree about a thousand cuts, and I'm often the kind of wild-eyed idealist that wishes that everything would conform to some universal set of gui standards.

Yep, now imagine you are visually or auditory impaired and need magnification or a screen reader.

Accessibility always ends up on people's "I'll think about that later" bucket, and it's terrible.

You can have real separate windows in egui. Either running on the same thread or another. See here: https://github.com/emilk/egui/blob/master/examples/multiple_...

I’m very sorry, but “native looking ui components” is a thing of the past.

I might put some effort in if developing on Mac (but even Apple just does whatever), but on Windows and Linux, the components are a free for all. If even Microsoft won’t respect their own UI, why should I?

I’m not advocating for breaking usability in your apps, just saying that we are well past not using this for desktop.

Which is a shame, because those widgets work infinitely better than the rough-shod ones thrown together by these all-in-one libraries, for the user.

If I have no choice, I'll use one of these apps. But if there's an alternative with a native UI, I'll switch in a heartbeat. Basically, the same as I feel about most electron apps.

> for the user

For which user? I prefer non-native apps. It makes me feel more immersed in the tool, and gives the developer complete control over their design, whether by choosing a GUI toolkit they like, or rolling their own from scratch to perfectly fit the domain.

I don't like it when developers break from the conventions and theming of my operating system because they feel entitled to. Sure, very sophisticated applications that have niche needs like Blender, Godot. Photoshop, etc may have a justification to do so. But most apps are not those and I expect them to be consistent with the rest of the software on my computer. It's very difficult to retrain nontechnical people to use apps when they break from the conventions and styles of the software they are familiar with.

The only justification that's needed is simply, because that's what they wanted to make. You can incentivize them to make something you want with money, but if they don't choose to they're not unjustified.

> they feel entitled to

They are entitled to. Just as you're entitled to use different software if you don't like it.

"native" widget sets have been dead and were killed off by the far worse electron/ad-hoc web designed apps

I’d be inclined to agree, but I would tend to be critiquing what GP actually said, which is the the gui is totally ‘non-native’. I think you were in part correct to read the ‘native looking ui’ portion into the comment though, it would seem to be a common refrain that gui’s need to appear conforming to the OS’s chosen aesthetic and visual formatting. However, a very real complaint echoed in a sibling comment is the failure of non-native gui’s to respect or implement the OS’s operating behaviors for gui’s. I have no issue with visual differences between applications, but I want clicking and keyboard behavior to remain constant across my apps.

As sibling implies, it’s a thousand small differences that build up, creating friction that foster the push to native GUI’s being the preferred, if not nearly mandatory, solution.

Reply on news.ycombinator.com