3 ms·
A big part of that historically was a GUI toolkit might need to build up a whole object model, render model, various container types, event loop, timer queue, n
by bfrog 3y ago
A big part of that historically was a GUI toolkit might need to build up a whole object model, render model, various container types, event loop, timer queue, networking, IPC, file system abstractions, internationalization and tools to deal with that, debugging and visualization tools, etc, etc, etc. For cross platform toolkits a whole OS and build system layer to deal with that as well. At least the ones people ended up using widely (gtk, qt, win32, cocoa, etc).
That's to say that a useful GUI toolkit has typically been a whole lot more than simply "draw me some widgets and let me poll on input events"
I wonder if that's really still as true though in newer (not C/C++) languages like Rust for example, where you can reuse a lot more of what the ecosystem and language already provide.
- jerf 3y agoI'm sure it shrinks the footprint a lot to just do "widgets" rather than being an effective VM, but even that is plenty huge. I'm not aware of any "non-mainstream language" having even that much of a toolkit. Plenty of partial starts, even starts that with another 100x the effort could compete fairly well, but nothing terribly close to "done". Someone may reply to me with one. I'd have to look at it and analyze. But I know I'm not going to get dozens of citations of high-quality toolkits of, say, the calibre that I can put rich text widgets with high-quality multi-font unicode support and everything else I want out of such a widget, into a tree control with those rich text widgets as my leaves, and have a million node's worth of rich text controls because they can be lazy-loaded based on visibility, just to come up with one use case.
- kitsunesoba 3y agoIt’s crazy how many newer UI toolkits (including those by giants like Microsoft) don’t even have a tableview/datagrid widget, which is one of the most common desktop widgets right after buttons. You’re expected to haul in some third party widget that’s half-baked and lacks battle testing or roll your own, which is ridiculous and a massive productivity + UX killer.
- hulitu 3y ago> don’t even have a tableview/datagrid widget, which is one of the most common desktop widgets right after buttons The newer UI Toolkits have only labels. Buttons, scrollbars, borders, menus, comboboxes cannot be implemented with the current state of the art technology. /s
- illiarian 3y ago> You’re expected to haul in some third party widget that’s half-baked and lacks battle testing or roll your own, which is ridiculous and a massive productivity + UX killer. Reminds of early-mid-00s and Delphi components. The standard components were fine, but lacked many important features (including Unicode!), so you'd hunt/shop around for third-party components.
- kitsunesoba 3y agoThis was the case for REALBasic too, which is where I first dipped my toe into programming. It was a wonderful intuitive learning environment (want to change what a button does? Double-click it to edit its code!) and could build to OS 9, OS X, and Windows with one click which was amazing, but it was very easy to hit the limits of what its standard widgets were capable of, which meant that you had to go get third-party widgets, most of which were commercially licensed (and meant most serious REALBasic apps used commercial widgets). That probably wasn't as much of a problem for a working adult but it wasn't much fun as a broke teenager itching to make things (as I was at that point).
- vetinari 3y agoBecause "mobile". Tables/grids do not work with mobile, so they are often skipped entirely. Annoying, I agree.