A few more for the list:

* Internationalisation

* Concurrency, parallelism, and perhaps async (probably less of an issue with modern C++, but Qt still has plenty on offer here [0])

* Integration with various platform-specific build tools and IDEs

[0] https://doc.qt.io/qt-5/threads-technologies.html

You do not need to replicate all features of Qt to make a GUI toolkit, especially since Qt tends to have a ton of stuff outside GUIs and actually has two "widgets" approaches (classic widgets and QML). For example the 3D API stuff are pointless beyond context creation, unless you use only that 3D API (instead of underlying window system functionality) to put stuff on screen.

Qt also recreates a ton of features found in C++ and if we're considering a new language, chances are the language itself has features that make Qt's unnecessary.

Which features are you talking about ? Even in c++23 there isn't yet a way to replicate moc, rcc, uic with the same ergonomy for the end user and the same efficiency.

I mean things like containers though in the context of a new language chances are the language itself may provide functionality that makes moc unnecessary.

Also you certainly do not need something like moc to make a GUI library, which comes back to what i originally wrote in that you do not need to replicate Qt to have a GUI library.

"containers" was not in the list.

There sure is some overlap with what Qt offers that most language offers (Containers, Networking, Database, threading, ...). But purely in the context of making a UI library, there is still a huge amount of things that Qt offers that needs to be replicated.

The post i replied to was about how big Qt is, which includes containers, etc. That the specific examples given did not contain "containers" isn't relevant since they are part of the "2 million LOC" mentioned.

Yes, you need to implement similar functionality, like abstracting the window system, input handling, text, etc but you do not need to replicate what Qt does to have a GUI toolkit.

Qt is very complex and Qt is (among others) a GUI library but Qt being complex doesn't mean that GUI libraries have to be complex.

...but, as others have noted, even if you want to only support the "core" features that most people would take for granted for a GUI (cross-platform, all the "usual" widgets including complicated ones such as RichEdit, ListView, TreeView, text with Unicode support and subpixel rendering etc. etc.) it's already a massive undertaking.

That is another issue, yes, it is not trivial (though it isn't like making a browser or even a game engine - especially since game engines nowadays tend to have their own GUI toolkits :-P) but my point was that you do not need to replicate what Qt does to have a useful and usable library.

Correct. You don't have to replicate anywhere near what Qt has to make a useful toolkit.

However, here is your experience with almost every other toolkit: Download it, compile it, build a couple test screens with it, maybe even build a couple of your production screens with it, then the inevitable disaster: You have some requirement, and you need a calendar that can highlight certain dates, or that gives you mouseevents on each individual date, or allows Jewish as well as Gregorian calendars, or that allows you to add things between the month name and the month days other than what the widget already puts there, or that... etc., for any of dozens of specialized requirements. And then you bounce off the toolkit and tell people in online discussions that you really enjoyed working with it, it was nice that it was so simple, and it has a lot of promise and you hope the developers keep working on it, but it wasn't suitable for your needs and Qt had exactly the widget you needed or at least the widget you needed had the plugin points you needed to do your job.

(In the meantime, the project stalls and dies because nobody else is using it either, but all for different reasons.)

And you hadn't even gotten a tenth of your dialogs started.

Another common one is, as people say, trying to add a rich text dialog and getting hit hard by bugs, counterintuitive behaviors, internationalization issues, etc.

Nobody uses all of what Qt offers. I can't even imagine what it would look like for a program to use literally everything it has. Even a full office suite would be pressed to do that. But everybody uses lots of different things. Put 10 Qt GUI users together and they'll use very different subsets beyond the bare basics like layouts and simple buttons.

Simply to write a binding to a GUI toolkit, ignoring all the other aspects of Qt, is itself a major project. There's been more than one Python project for it, and it is a project, generally more than one person could hope to do. To write a full toolkit that won't give people the experience above is enormous.

And that is why it is important to select your language carefully if you're writing a GUI-heavy project. You can't just pick up your favorite language and casually expect every widget you need to be available. Even if you nominally have "a binding to Qt" in your language, in my experience it's important to still double check that the binding to the widget(s) you need actually work, because anything beyond those bare basic layout, buttons, and bindings to simple widgets everybody uses is still quite possibly broken, or incompletely bound so it can't actually be used (which means nobody can have ever even tried this widget), or straight-up missing, or it's present but there's no way to correctly subclass something then make the bound widget use your subclass (in the foreign language) correctly, or something.

Nor can you just bide your time and hope a toolkit appears. They're enormous projects, even just to get one to the point that most developers don't generally hit a vital bit of missing functionality, let alone to get one full of all the features someone could reasonably want.

Sorry but my experience with Qt has been neutral to negative. I can go and write a textwall about all the issues Qt has and personal experiences i had with it myself, but they're not really relevant here. Your message is basically "people stick with Qt because people stick with Qt so that is the safe bet" (aka "nobody was fired for buying IBM"). Which sure, it is true and a big reason why you do not see other toolkits much, but this doesn't really have to do with what i wrote.

Grandparent's point is that, in something with less functionality, you will hit missing feature X quickly, and it won't be the same missing feature as any ten random other developers. It is just your interpretation that it is, somehow, primarily about inertia or image. Joel on Software has an essay about (missing) features: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

I get that point and i disagree because it makes two assumptions:

1. That you need to replicate Qt to have the same or equivalent features for a GUI toolkit (remember that what i made explicitly that Qt is more than just a GUI toolkit) or you will not have the same features at all

2. That you will "hit" said missing feature

None of these have to do anything with making a GUI library though. #1 is especially questionable since even if you need the non-GUI functionality Qt provides, it might be something the language already has (remember that this is about other languages aside from C and C++) and/or you may even find a separate library that provides such functionality.

And yes, inertia and image does affect A LOT. People do choose projects only because of the perceived safety of those projects from being used by other people. This is why regardless of features, many people stick or flock to languages/libraries/frameworks/etc for their communities and "community" or "ecosystem" is a common concern about something new. This is something you can see often in Hacker News posts too.