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.

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.

> It's not too hard to get an AppKit/Cocoa project from the early 2000s compiling on modern macOS, but Cocoa had already accrued 20 years of age by 2005

That's a mindboggling thought. How much did 2005 Cocoa have in common with 1985 Cocoa? (That's a real question, I have no idea)

Qt and GTK were released (or first labelled stable) in 1995 and 98 respectively, so 20 years gives us 2015 and 2018 which is well within the Qt5 and GTK3 era.

For Qt, I would say Qt4 in 2005 marks a point of maturity. After that there have been whole substructures and programming idioms added and removed and all sorts of things tidied up, but anything you wrote directly to Qt4 is going to be conceptually similar in current Qt versions.

The Qt2 to Qt3 and Qt3 to Qt4 transitions (I never used Qt 1) broke almost every line of Qt code, but from 4 to 6 is a different prospect. It's a question of updating some details and seeking replacements for specific APIs that haven't been carried across. That can be difficult or totally blocking but it's quite different from having to rewrite everything.

1985 Cocoa and 2005 Cocoa are very similar - I would guess there are less new things than there are in moder Cocoa and 2005.

Except - not strctly Cocoa but memory management has changed a lot and might have changed some APIs.

1985 just had malloc and free or [Class alloc] and [object free] 1986/7 introduced autorelease and retain. 2009? had garbage collection and then 2010? had the autorelease and retain automated (ARC).

Memory management has not changed. It's just hidden by the compiler. There are just three ways doable: RefCounting, GC or manual.

But a few things changed considerably. The background models and that now you go away from NSCell objects to child windows is the step and the required step to get stuff onto the GPU. The next one is Recycle View anything, removing the concept of NSOutlineView to NSTable View.