Why 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".
I think what happened is that a combobox and dropdown-list merged, because basically the combobox is an editable dropdown list. Qt's QComboBox definitely combines them. Apple does not (NSComboBox is editable, NSPopupButton appears to not be). Not sure what Windows or GTK do.
In some widely influential toolkits, like Win32[0], this is just a part of the style state and even comboboxes without text fields are called comboboxes.
So the name stuck. It isn't really much different than calling them "radio buttons" even though they have nothing to do with radios.
> It isn't really much different than calling them "radio buttons" even though they have nothing to do with radios.
The button set on the face of many dashboard radios would physically pop out the previously pressed button when you pushed a different one in so only one in the set would be selected. The name is pretty obvious if you've used the physical version but I haven't seen one since the 90s.
Yes, i know this backstory which is why i mentioned radio buttons: they called like that because of some historical reference, not because they have anything to do with radios.
Similarly comboboxes are called like that because of historical reference (to the combobox control on Win32 that provided the functionality) even though they aren't really a combination of input box and list.
(though one could claim that they are still a combination of a button and a drop-down list, so the name still has some relevance to what is displayed, unlike radio buttons)
Parent 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.
There'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?
It 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.
Definitely, 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.
Text 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.
The 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.
Non-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.
Yeah, 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.
https://emilk.github.io/egui/index.html