Remix.run Logo
bschwindHN a day ago

Devs are constantly making the mistake of falling in love with immediate mode GUIs... because it's convenient for them, the developer. For the user, it's almost always a worse experience as things don't behave in the same way as the rest of the platform they're on.

egui is great for video game debug UI overlays and internal tools, and maybe some specialized graphical tools. Otherwise its quirks are too annoying for general purpose app usage. Sure, you banged out a UI quickly with it, at the expense of your users.

piker 21 hours ago | parent | next [-]

No, it’s fine. It’s the longer term DX that takes a hit. Anything other systems can do, immediate mode can do, because like those systems you can always cache across frames. The same can’t really be said for retained mode. We wrote some about it here: https://tritium.legal/blog/desktop

magackame 21 hours ago | parent | prev [-]

Can you list your exact complaints? It's a GUI like any other.

bschwindHN 19 hours ago | parent | next [-]

Alright I downloaded the thing, just for you.

* Right off the bat in the login screen, if you resize the window, it flickers

* I logged in. Double clicking the top part of the window doesn't maximize it, like I expect on basically all other windows. I'm using MacOS, btw

* Resizing the main home screen is also a flickery mess. Though I'll give credit, it's a fast flickery mess, because the official spotify app resizes like ass

* Okay, here's one more specific to egui and why I think its approach is not good outside of the app types I listed in my original comment: I type some text in the search bar. Let's say I want to highlight the last word after I've typed it, in order to delete it or type something else. On every other app on my system, I can hold Option + Shift + Left Arrow Key. Or perhaps Cmd + Arrow Keys to move the cursor to the start or end of the line. The egui app just doesn't work, because egui misses so many fine details about text manipulation on a given OS.

* In general, text handling just sucks

* Scrolling doesn't have the inertial bounce when it hits the ends of a scroll action

* It's very easy to create overlapping UI elements by resizing panels and/or the window itself.

Anyway, those are just some of the things from a few minutes of trying this specific app out.

In general, if it's an egui app, I already know there will be weird resizing glitches/flickers, a poor text editing experience, and it will typically not follow the platform's idioms and built-in gestures, scroll physics, behaviors, etc. In this case, the app is decent since it mostly just needs to play music, and you mercifully don't need to interact with it much when it comes to text and such.

But saying "It's a GUI like any other" is like saying "wonderbread is a bread like any other". Maybe it's a curse of knowledge? Similar things happen with coffee. One person says "tastes like coffee" while another can pick out individual flavor notes. Maybe I'm shouting into the void and no one gives a shit anymore, I dunno. But to me, these things matter and are a mark of quality.

If we have LLMs that can shit out whatever code now, why aren't people having them output truly "native" GUIs that use the UI framework of the OS so they can get all the expected behaviors by default?

wasmperson 16 hours ago | parent | next [-]

This seems like more of a complaint about egui's choice to re-implement all the widgets from scratch than its choice to use an immediate mode API. The two are orthogonal. The IMGUI idea has its roots in a community of people that like implementing things from scratch, but you could implement it on top of native widgets if you wanted to.

The choice to re-implement native widgets from scratch is justifiable if the egui devs think they can do better than the native widgets do. It's also nearly required in practice if they want the toolkit to have consistent behavior across multiple platforms (something people have learned the hard way multiple times across multiple different UI libraries).

It's hard to get it right, but that's why the egui devs are writing a library: so that others can benefit from that hard work. Many of the things you pointed out are just bugs, and bugs can be fixed.

bschwindHN 2 hours ago | parent [-]

> but you could implement it on top of native widgets if you wanted to

Is there an immediate mode GUI API that uses native widgets? I don't think I've ever seen that but would be curious to try it out. Does it work well in practice? If it doesn't exist, then it's kind of a moot point, isn't it?

I sympathize with wanting "consistent behavior across multiple platforms", but that usually just results in "consistently kneecapped behavior across multiple platforms".

Klonoar 15 hours ago | parent | prev [-]

You should draw a distinction between “implementing the GUI” and “implementing OS behavior”. Flickering aside egui works mostly fine for the former; the latter falls apart on most non-browser-and-non-toolkit-wrapper approaches because people never stop to handle those things.

E.g your double click on title bar thing sounds less like egui to me and more like somewhere in the stack is missing an AppKit flag.

theodorc 20 hours ago | parent | prev [-]

[dead]