12 ms·
Egui: An easy-to-use immediate mode GUI
- ducktective 5y agoBe sure to checkout the web demo, quite impressive IMO: https://emilk.github.io/egui/index.html https://emilk.github.io/egui/index.html
- athorax 5y agoThe font rendering is almost unreadable on my machine, but the functionality seems to be there
- Jackson__ 5y agoOn windows 10 here, the font rendering was also what put me off immediately in the demo.
- wongarsu 5y agoIt seems like the font rendering doesn't do any antialiasing (other things are antialised, you can toggle it in backend/settings). The result is pretty painful to look at small sizes, unless you compensate with screen resolution (as apple now does). Zooming the page to 130% gives me a quite acceptable experience.
- rkalla 5y agoSame - Fedora 34, nvidia driver. Excellent performance though.
- elpocko 5y agoWhy does every IM UI library have a dropdown widget that they call "Combo box"? Dear IMGUI, Nuklear, this one does it too. A dropdown list is not a combo box - a combo box is a text input box combined with a dropdown list. This "combo" aspect is missing in all these frameworks, but they still call their simple dropdowns "Combo box".
- deleted 5y ago[deleted]
- stagger87 5y ago> Why does every IM UI library have a dropdown widget that they call "Combo box"? They can call it whatever they want? > A dropdown list is not a combo box Who says?
- thrower123 5y agohttps://docs.microsoft.com/en-us/windows/win32/controls/combo-box-styles https://docs.microsoft.com/en-us/windows/win32/controls/comb... The Win32 API is going to continue to drive naming conventions when all of us are dead. But yeah, the difference between a combobox, a listbox, and a dropdownlist is just a flag value.
- karmakaze 5y agoThere's actually a separate ListBox control. And I never thought of it at the time, but why does an option turn a ComboBox into a DropDownComboBox, but an option doesn't turn a ListBox into a DropDownListBox? Oh no, it's all coming back to me, because ComboBoxes were added later and rather than change ListBox they added DropDownList functionality to ComboBox. I also don't see an option in ListBox to make it multi-select, was it all horribly done in the notification handling code?
- abraae 5y agoParent has been down voted to oblivion but they make a good point - arguments over words and names seldom produce any interesting discussion or definitive conclusions.
- cjaybo 5y agoI use JUCE a lot and they have use the ComboBox name as well. Always reminds me of creating custom levels in THPS...
- 5y ago
- dleslie 5y agoI can't seem to select any text on my phone.
- 4fips 5y agoText in labels and other controls is not selectable (unfortunately), in this regard egui behaves as a native app, so mostly just editable texts are selectable. This feels a bit unnatural on the web, but one must consider that egui uses a custom WebGL renderes, so the content is not backed by standard DOM.
- savolai 5y agoOn native apps with Qt text on any widget can be made selectable via a property.
- 4fips 5y agoYeah, I would like to see that behavior as an option, or even better allow to select the whole UI as a block of text (to feel natural and be searchable on the web). I belive any UI (incl. native) should not prevent you from copying any text.
- wongarsu 5y agoThe text in the textbox is selectable, so it's not like egui can't handle text selection. It's just following convention with making GUI text unselectable.
- formerly_proven 5y agoNon-copyable texts by default in "native" applications sounds reasonable but is actually one of those things that introduces unnecessary friction down the line when users try to write tutorials or reports and have to manually type out everything.
- monocasa 5y agoYeah, it's not using the dom, it's using a canvas with webgl.
- mastax 5y ago> NOTE: The WebGL backend does NOT pass the color test. > This is because WebGL does not support linear framebuffer blending (not even WebGL 2!). > Maybe when WebGL3 becomes mainstream in 2030 the web can finally get colors right? Yes, I had to transcribe this manually because I couldn't copy and paste it.
- weavie 5y agoThis is quite standard desktop gui behaviour.
- danShumway 5y agoDefinitely, but I think part of the underlying criticism here is that standard desktop GUI behavior on text selection and copy-paste is bad, and we're kind of questioning whether it's good to encourage the web to continue moving in that direction.
- Rd6n6 5y agoThat official egui demo is phenomenal.
- micheljansen 5y agoThis is way snappier on iOS than I would have expected. Feels faster than most web apps.
- theiasson 5y agoAs a user of a keyboard driven browser, I hate it. I hope this trend of rendering the whole page on html canvas never catches on.
- 4fips 5y agoI'm using it for some of my little tools, and it's pretty seamless going between native and web, which I appreciate a lot, and unlike other non-native UI frameworks, navigating through egui feels pretty natural (the way input are handled etc).
- dleslie 5y agoHow is it for accessibility? Looking at the custom widget example didn't leave me with the impression that it has that in mind, but I could be mistaken.
- 4fips 5y agoYeah, I believe accessibility is not addressed at all. Similarly when compiler for web, it would be great if the UI would actually behave as text (actual web page) and could be copied into the clipboard etc.
- da_big_ghey 5y agoWhy is everyone concern with accessability on small gui tool? Someone make a cool project and always hackernews with the question on how it serve this very small demographic.
- savolai 5y agoThe point of accessibility is not minorities, but taking all users in various circumstances into account. Sometimes you may yourself be on a device where images do not show and you need alt text, or where you need to resize fonts to be able to read text.
- fsloth 5y agoAccessibility is probably a good way to discern is gui usable for a particular use where one needs accessibility. It's an interesting feature to have for many. I don't ever read it as a way to disparage the gui (guis after all are quite hard to implement - any experimentation no matter how playfull is probably more than welcome in this space).
- yosamino 5y agoI think I get what you mean: the percentage of people who access the web using a screenreader is not huge. That doesn't mean we should discount it, it's just common courtesy and it's a legal requirement in many circumstances. But if you take one step back, the demographic is not very small at all! It includes everyone who is a bit older and maybe can't see as well as when they were 23, so they like to increase the contrast a bit. I myself am not very far above 23 and I read hackernews zoomed in to 130%, it's just more readable. Many people have an easier time using a computer by for example making buttons larger so that a mouse can click them faster. There are more examples. And last but not least: Writing functional UI tests for applications is enabled, in a good chunk by accessibility capabilites built into the gui toolkit. My job would be much harder if that wasn't baked in to most UIs. So, while I agree with you: let people have fun playing with technology and create new things without having to implement everything from the beginning, I don't think it is fair to just dismiss accessibility concerns like that.
- darknavi 5y agoI haven't looked at the usage pattern/implementation but the visuals are much nicer to the eyes than ImGui[1]. 1: https://github.com/ocornut/imgui https://github.com/ocornut/imgui
- adamnemecek 5y agoI get why people like immediate mode GUIs but the performance tends to be pretty bad.
- joshmarinacci 5y agoBad is relative. If it's a game where you have to repaint the entire screen anyway, then it doesn't matter. But a lot of potential optimizations are lost when you don't use a retained scenegraph.
- runawaybottle 5y agoI mean, I’m looking at this on mobile and desktop and just like a another poster mentioned, in relative terms, the damn thing is smoother than most web apps. What’s the end goal here, right? The web sucks at the moment and I’m open to all ideas.
- naasking 5y agoSmoother yes, but to be fair how much CPU and power is it using? That's invisible to you right now so appearances can be deceptive.
- andrewmcwatters 5y agoAs soon as you want to do anything remotely as complex as the web does, like say arbitrary UI element sizes with scrollable overflow, you immediately have to do the same thing CSS 2.1 rasterizer engines do.
- runawaybottle 5y agoI think you are just dead wrong about this. I’ve played video games my whole life and they always always had more complicated UIs, akin to web apps. It’s always been a richer experience.
- andrewmcwatters 5y agoI am the author of a CSS 2.1 rasterizer, as well as the author of GUI software for game engines. They have different ways they draw user-interfaces. CSS 2.1 and the associated modules and extensions to it that you would use today to build UIs are much more complicated to implement than game engine UI. If the opposite were true, you'd see more web browsers that weren't KHTML derivatives, but that's not the case.
- transfire 5y agoNeeds copy and paste?
- biryani_chicken 5y agoIs this Rust only or is there bindings for C?
- pornel 5y agoIt takes advantage of Rust's closures for convenience, generics to avoid pointer indirections and heap allocations, and Drop for automatic memory management. The API isn't complex, so it may be possible to export a C-compatible wrapper, but due to lack of the aforementioned language features it may be less optimized and less ergonomic.
- Shadonototro 5y agoVery slow to compile, on top of being over engineered with dependencies Also something seems very weird with the way they render their fonts, it's very blurry (could be the font+size that is the issue) nuklear or imgui are much better at doing immediate mode GUIs without dependencies
- soheil 5y agoReminds of highly interactive older Windows programs, like Photoshop. Every slight mouse movement gives you some sort of feedback, every click makes a change, everything is snappy... I like those things and I'm sad the web took them away. On the web everything is dull and dead, you can tell it very much was designed for reading.
- sodality2 5y agoI use this in a few of my projects. Simple, no complaints. Compile time is faster than it takes for me to yawn most of the time (using mold linker and sccache, which improves compile time a lot with a far superior linker and caching compiled dependencies, respectively). (Edit to add: below complaint is entirely within rust and irrelevant to this library) Only problem (not the fault of egui) is sometimes the elements disallow me using the templateapp object mutably as a whole: sometimes I have to mut borrow a part of `self` before the ui part (instead of mutating `self.whatever` within the UI element, I have to do `let borrow = self.whatever.borrow_mut()` before the UI element then call that borrow) which seemed odd to me as a beginner. I think this is mostly a rust "problem" but also maybe because of how UI element creation was designed. If you understand the borrow rules then you'll probably understand it fine. I might be able to just lock an Arc Mutex instead and avoid the problem but I just learned how to use them so :p
- pornel 5y agoThe awkwardness is because use of `self.whatever` in closures borrows `self` as a whole instead of just the `whatever` part. The good news is that Rust is going to fix this soon: https://blog.rust-lang.org/2021/05/11/edition-2021.html#disjoint-capture-in-closures https://blog.rust-lang.org/2021/05/11/edition-2021.html#disj...
- sodality2 5y agoThank you so much! that's very interesting.
- Arnavion 5y agoIf the problem is as pornel described, you can work around it by creating the borrow of self.whatever outside the closure. Instead of: foo(|| { bar(&self.whatever); }); ... do: let whatever = &self.whatever; foo(|| { bar(whatever); }); To avoid leaking `whatever` into the scope, there's an idiom that looks like this: foo({ let whatever = &self.whatever; || { bar(whatever); } });
- soheil 5y agoI just couldn't resist posting this here from one of the files comment section: iOS-style toggle switch: _____________ / /.....\ | |.......| \_______\_____/
- freemint 5y agoNot sure if that would look better: _____________ / /.....\ ( (.......) \_______\_____/
- rasz 5y agono error checking = browser with no webassembly fails silently with no error messages
- paulgb 5y agoMaybe I'm misunderstanding what you're trying to say, but I don't see how that's a criticism of the library. You can't really do WebAssembly feature detection from within a Rust library compiled to WebAssembly; that's the responsibility of the JS loader you use, not your UI library.
- bionade24 5y agoHow about Wayland ? Or does it need Xwayland?
- no_time 5y agoLooks pretty nice apart from the font rendering, which is terrible. It looks half decent with the default color scheme but when you switch to the dark mode it really shows. I'm using a regular 1920x1080 27" display for reference EDIT: the unhinted editor font looks good.
- sodality2 5y agoOddly enough it's the inverse for me: I can hardly read the light theme one.
- paulshen 5y agoI investigated egui early this year. It's a very good library! For me, getting used to immediate mode UI was a change from being used to DOM / React-style UI. imgui works well for a lot but it struggles with complex layouts, eg flexbox. This is acknowledged in egui's README Couple things I built with egui: https://artifacts.bypaulshen.com/rust-gui/code-render/ https://artifacts.bypaulshen.com/rust-gui/code-render/ https://artifacts.bypaulshen.com/rust-gui/tictactoe/ https://artifacts.bypaulshen.com/rust-gui/tictactoe/
- capableweb 5y agoCould you possible share the source to your two examples? I'd love to see how much is accidental complexity vs actual complexity, compared to how web UIs (and other similar paradigms) can be built almost in an almost fully declarative way.
- paulshen 5y agoHere's the main file of the tictactoe implementation. https://gist.github.com/paulshen/b04db68c754f73e693cd29a481c9ebea https://gist.github.com/paulshen/b04db68c754f73e693cd29a481c... `update` is similar to React's render function except here it's being called on every interaction (eg mousemove tick) and redrawing the entire screen from scratch! The code runs so fast that this is fine from a perf standpoint. Note that egui has a reactive or continuous mode. You can rerender everything from scratch 60fps (continuous mode) and it'd be fine in most cases.
- brundolf 5y agoPart of what makes the DOM slower by comparison is the fact that it supports such advanced, declarative, adaptive layouts. There's a tradeoff for having that vs not having that
- fluidcruft 5y agoTic-tac-toe is frustrating me because I can't seem to force it into a draw.
- 5y ago
- syrusakbary 5y agoI was playing last week with this framework. One of the best things that Egui does is updating the layout using a reactive rendering strategy by default. So rather than doing a paint per frame (each 15ms), it does it lazily only when the state changes. For example: if you have a plot that updates each 10ms... a UI paint will be triggered each 16ms (up to 60fps I believe). If not, the UI will be updated lazily (when you move the mouse or other event happens). Note: you can choose a "continuous" rendering mode for the backend as well. It also has great accessibility with a built-in screen reader. It's an impressive piece of work.
- andrewmcwatters 5y agoThis is an old UI redraw strategy. It’s been used since the dawn of GUIs and is referred to as invalidation. Here’s an example of a standard GUI invalidation event: https://github.com/Planimeter/grid-sdk/blob/master/engine/client/gui/handlers.lua#L148 https://github.com/Planimeter/grid-sdk/blob/master/engine/cl... As you mentioned, most GUI software invalidates primarily on mouseovers, and individual components handle things like invalidation on focus.
- mahoho 5y agoegui (えぐい) is Japanese for "harsh (taste, feeling, etc.); acrid; pungent; astringent "
- lioeters 5y agoIt's also a slang term meaning "awesome; amazing; incredible; cool". https://ejje.weblio.jp/content/えぐい https://ejje.weblio.jp/content/えぐい
- innocenat 5y agoOne thing I wish every immediate mode GUI library would show is how it handles complex script like Thai, Arabic, etc. because it's quite hard to get it correct, but it's also the hard requirement if your application need to support those language.
- Decabytes 5y agoI've always enjoyed making little apps with Immediate mode GUIs. It's a shame that they aren't as effective as retained GUIs for more complex apps. When I was still programming in Rust FLTK was the only GUI I used that both worked on my Raspberry Pi 4 and was something I felt like I could grasp. I'm not sure if that is retained or immediate or not. I wish the OS maintainers would all get their act together and create an api that made creating cross platform GUIs easier. You can't blame people for using Electron when you see the state of desktop GUIs 1. https://github.com/fltk/fltk https://github.com/fltk/fltk
- DennisP 5y agoWhy aren't they good for more complex apps?
- lazypenguin 5y agoLayout becomes challenging after a certain point with ImGUI. Especially if your layout "flows" based on the state of existing elements. This can require multiple draw passes in ImGUI to get certain effects and outcomes.
- beagle3 5y agoFLTK is retained. It’s, from my experience, the sanest of all toolkits - much easier and simpler to use than almost any other, for 98% of tasks, and usually faster. Back in 1998(!) when I started using it, it was also the only flicker free one for Windows and X (without very significant effort) although I believe that gap was finally closed circa 2008 or so.
- louib 5y agoThe project depends on `libspeechd-dev`/`speech-dispatcher-devel`, but there's no mention of support for voice commands. Does the framework support speech recognition? That could be pretty neat.
- danShumway 5y agoI've had this fight a dozen times and there's nothing really new for me to add, but I consider GUI frameworks that target WebGL and Canvas for their basic elements like text and sliders to be usually harmful, for multiple reasons[0]. That being said, some (imo high) praise: - Demo is faster than most other WebGL/Canvas-backed frameworks that I've looked at in the past, including Flutter and Qt. It easily blows them out of the water. - Demo works in Firefox - Demo respects platform scroll direction(!!!) - Demo supports platform-specific cut/paste(!!!) - Demo responds to (some) browser zoom events(!!!) - Demo is at least semi-responsive (again, compared to Qt/Flutter this is miles ahead) - Demo handles touch events - A ton of impressive attention to detail around UX affordances like showing link locations and tooltips on hover. Clearly focused on actual usability, not just on showing off tech. - Just again stressing that interactions are really snappy and performant. Kind of starts to chug if I open a ton of windows, but... I'm comparing this to the last Flutter demo I saw on HN; the performance is great. ---- And some criticism: - Evergreen accessibility concerns (I've seen some conversations about exposing a separate API, this... misses some of the point of how accessibility on the web is designed to work imo. Also, the DOM is an accessibility layer. I don't understand why we keep reinventing the wheel here, I don't understand why we're recreating content trees to send to screen readers when the browser has a content tree baked in) - Search doesn't work at all - No right click menus anywhere - Font rendering appears to be heavily platform/DPI dependent (?), on some of my screens the whole app just looks blurry, I would abandon any app in the real world that had fonts that looked this bad on some of my screens. - Copy/paste/text-selection disabled in most of the demo (for example, no way to copy links) - Good on the demo for catching platform settings for scrolling, but it doesn't catch any of my other custom keyboard shortcuts or gestures. Even some stuff that's not platform-specific: I'm not sure why page down/up isn't getting caught. - Demo blocks some mouse gestures that should filter up to the browser level (pinch to zoom, etc) - Demo has no fallback if WebGL isn't enabled, which makes this solution unworkable for anyone configuring their browser to avoid fingerprinting (hopefully Firefox will make this concern go away in the future by bundling WebGL permissions into Canvas permissions. This is not really the author's problem to solve, I don't think). - Evergreen criticism that demo does not respect my font choices or work with any of my browser extensions. This is the important thing, because I still don't see how (short of re-implementing the entire DOM) a GUI framework like this is ever going to respect my browser settings and extensions. You can polish a GUI framework for eternity, that doesn't mean 3rd-party extensions are going to start working with it. This is a huge step backwards for the web in my opinion, I regularly customize and extend the sites I visit. There's no way for a developer to allow that using a framework like this. ---- TLDR I think this is easily the best Canvas-backed GUI demo I've seen so far, the author(s) should be very proud of it. I can't speak to its native performance but I'm seriously impressed by how the demo performs in the browser. Also seriously impressed by some of the little UI touches I'm seeing. I can't stress this enough, good job. However, this is still not the right way to build a cross-platform GUI that targets the web. The demo still has serious flaws that aren't the result of a lack of polish, they're the result of the rendering target itself. I still heavily advocate that people trying to build GUIs for the web use something else (even for the stated use case of a simple GUI). There are multiple cross-platform GUIs that will spit out actual DOM content. A polished cross-platform GUI that spits out HTML instead of pixels as its render target won't have the problems that I listed above. I understand that working with HTML is frustrating, particularly in some native circles where the way developers think about UIs is primarily visually. But the DOM is not a framework for displaying visual graphics, the DOM is a render target. A lot of benefits on the web stem from the fact that we treat the DOM as its own render target. That philosophy is why a lot of extensions and behaviors on the web are possible. No rule is absolute, there are instances where WebGL is the right choice. But for most frameworks, particularly frameworks that are displaying text data, it's not. This focus on taking the DOM out of the picture to get rid of the messy details of how it works is a bit like arguing that the best way to improve command line interfaces is to abandon text and start streaming OpenGL buffers to the terminal output. It's missing the point. Yes, working with the DOM is frustrating, but a lot of the frustrating parts are a result of the medium itself. The DOM is part of the user interface. ---- [0]: https://news.ycombinator.com/item?id=27132087 https://news.ycombinator.com/item?id=27132087
- gavinray 5y agoSomething interesting to think about: - This has a framework "eframe" which lets you write generic apps which can be rendered and run either natively on on the web with WASM: - https://github.com/emilk/egui/tree/master/eframe This has me thinking -- there's an existing standard "Web Audio Modules (WAM)" which never really went anywhere: https://www.webaudiomodules.org/ https://www.webaudiomodules.org/ I'm imagining some way of bridging the VST3 API's and the WAM API's, so that you could write code using "eframe" that would run either as a natively compiled VST plugin, or in a browser and using the DOM audio API's as a Web Audio Module. native -- glium (OpenGL) -- --- VST3/LV2 API "Adapters" / \ / eframe --- Generic Audio/Synth/FX API's \ / \ web ----- WASM (WebGL)----- --- Web Audio Modules API "Adapter" Wouldn't something like that just be really friggin cool? I'm not big-brain enough to figure out the details or if it's even viable, but damn it would be revolutionary.
- gameswithgo 5y agoFiguring this stuff out is mostly grunt work, see if you can get a minimally viable prototype going, then maybe you can attract some big brains to refactor and improve and make it into something.
- prionassembly 5y agoThis looks like a good excuse / starting point to learn Rust, but available documentation is basically tutorials that are hard to follow without knowing Rust. (I did work through Rustlings but mostly forgot it). Of course, it's unfair to ask of any library to provide an intro that also presents the surrounding language. But Rusteros are always so eager to gain converts so... hey, here's a tip.
- deleted 5y ago[deleted]
- radarsat1 5y agoThe plot widget is pretty nice. Makes me wonder if it could be an interesting frontend for viewing data in Python, like a realtime-capable, GPU-driven, web-friendly matplotlib.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- videogreg93 5y agoI've been looking for an immediate mode GUI library for LibGDX, I might have to write a port of this. I'm struggled many times to get ImGUI working nicely with LibGDX but it's never worked for me.
- kderbyma 5y agoI have been enjoying it so far as I explore rust. it's quick and the webasm is a big winner!
- MrWiffles 5y agoI took a look at the GitHub repo and I understand this is a GUI library for Rust, but I don't quite understand what they mean by "immediate mode" - could someone elaborate on that, please? Thank you!
- otoburb 5y agoA section in the GitHub README tries to answer this question: https://github.com/emilk/egui#why-immediate-mode https://github.com/emilk/egui#why-immediate-mode. I also read an old 2005 blog post & video by Casey Muratori[1] that explains the differences in more detail. [1] https://caseymuratori.com/blog_0001 https://caseymuratori.com/blog_0001
- accountofme 5y agoImmediate mode guis, afaik started in games. The GUI is written on every frame of the game, layout and state (i.e. button presses) are handled in code.
- bmn__ 5y agoNo, it started in the CS laboratory. The first GUIs were immediate, then this concept was quickly abandoned because of the numerous short-comings. Where GUIs mattered, the retained mode ruled supreme.
- accountofme 5y agoTil. thanks
- jbritton 5y agoOn iPhone Safari, I can’t change the Combobox value using the Combobox widget.
- jbritton 5y agoI see many complaints about the font rendering and I also agree the fonts don’t look good. This is a general problem with OpenGL. OpenGL draws triangles. There is no support for antialiased text rendering. And if one can figure out how to render live text with OpenGL, it won’t be something a GPU is efficient at rendering. I think the normal approach is to pre-render all needed glyphs and then move them into position. Pathfinder, Slug, and the work from Raph Levien are the only projects I know working on GPU based font rendering.