| ▲ | bschwindHN 20 hours ago | |||||||
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 17 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. | ||||||||
| ||||||||
| ▲ | Klonoar 16 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. | ||||||||