Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

There is a widespread lack of understanding of just how staggeringly large a high-quality GUI toolkit is.

Across a number of minority language communities I participate in, there's a constant stream of "Why isn't there a good native GUI toolkit in $MY_FAVORITE_LANGUAGE yet? All the ones I can find suck." questions, to which the answer is, you're asking for a project that can easily be on the order of magnitude of all the other Open Source projects in the language combined, if not greater. What you get with less than effort than that are the aforementioned "suck"y GUI toolkits. Which I celebrate and praise, but realistically, just getting a production-grade "rich text widget" is alone a staggering undertaking, let alone everything else that goes into a GUI toolkit.

Just a project to bind an existing GUI toolkit into your favorite language can easily overwhelm a dedicated team of multiple people, and as annoyingly complicated as that can be, it's wildly easier than building the entire toolkit.

Getting to "maturity" is a really, really hard problem.

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.

I'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.

It’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.

> 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.

This 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).

Because "mobile". Tables/grids do not work with mobile, so they are often skipped entirely. Annoying, I agree.

> 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

> Just a project to bind an existing GUI toolkit into your favorite language can easily overwhelm a dedicated team of multiple people

I have to disagree, it's not that hard and can be done by one person. Red language did it, it has very clear declarative GUI toolkit for Win/macOS/GTK in <2MB executable. So no, it's not that hard.

At 2MB in size, I guarantee you beyond a shadow of a doubt that it does not satisfy the test I gave in my other message, nor does it pass the test that if you ask a designer to design you a form, the toolkit will be able to do what the designer wants.

At that size you've got a programmer GUI toolkit, that as long as it is used by a programmer who is willing to live within its constraints, it will work fine, but it won't satisfy anyone else.

To put it another way, Window's Wordpad is an OK document editor, if you're happy to live within its constraints... but it's no replacement for a Word document being shared over Sharepoint with change tracking between multiple people before finally going out to 1,000 people via a mail merge. There's a ton of Wordpad-class GUI toolkits. There's not very many Word-class GUI toolkits.

I mean, I'm sure Tk is much more featureful than can be fit into 2MB and it's honestly barely in the "works for programmers" class. It's really nice for programmers, too, but it isn't going to replace QT anytime soon.

What has Sharepoint to do with a GUI Toolkit ?

In that metaphor, the 2MB GUI toolkit is Wordpad, and QT is Word.

I find the analogy particularly apt because it is often said of Word "Everyone uses only 10% of Word but everyone uses a different 10%", and the same is true of GUI toolkits. Once you get out of the super-basics of text widgets and radio buttons, you're in a hugely diverse world where nobody is using the same thing but to be a "real GUI toolkit" you need to support them, like, table widgets with complicated lazy loading, rich text widgets rich enough to implement a full custom editor, arbitrarily complicated graphing libraries, OpenGL support, internationalization and FULL Unicode support (far beyond merely the rendering of text), and so on and so on. I mean, take a minute and click through this: https://doc.qt.io/qt-5/classes.html Some of it is because QT is also a framework, but a lot of it is there for a GUI toolkit reason.

Just blipping through that, a list of features that are absolute drop dead requirements for someone out there that I didn't think to mention includes: Printer support, animation support, OAuth support, canvas support, filesystem support (for that open dialog and friends), font interaction for if you need direct rendering, help support, alternate calendar support, video support, and who knows what else I missed. Few apps need all these things, but there's plenty of apps in the world that absolutely, positively need at least one of those things.

Reply on news.ycombinator.com