Yeah, of all the popular C++ tookits listed in the site, my personal "favorite" is wxWidgets (favorite in quotes because i do not really like it, it is just the one i found myself being more comfortable with). We're using Qt at my current job and while i'm ok with it, i still like working with wxWidgets more than Qt (even if Qt is certainly more polished).
I found documentation fine with both toolkits, although i really like that wxWidgets's docs are in CHM format so i can quickly search and scan them locally with a handy tree of contents at the side. With Qt i have to use the online docs and searching goes through Google which slows things down (...there might be some offline docs at the Qt site to download, but i couldn't find it).
You are missing some documentation packages or they somehow went missing from the index. You can add them (.qch files) in the settings menu of Assistant.
If you install Qt through the installer (which would be the main way of getting it on Windows), your installation should have a "Docs" folder containing HTML files.
Many Linux distros package it separately, e.g. on OpenSuSE it's in "libqt5-qtdoc" and its subpackages.
I didn't installed Qt myself, it is part of the repository (gamedev, we put everything in the repository :-P). Perhaps i'll try to install the same version of Qt somewhere separately and see if the docs are there.
Note that the Free Pascal/Lazarus equivalent to VCL is two libraries: FCL and LCL, with the former being part and developed by the developers of Free Pascal and the latter being part and developed by the developers of Lazarus (while there is an overlap, they are two different projects with different teams). FCL is also used by other projects (e.g. FPGUI uses FCL but not LCL) and if you install just Free Pascal you only get FCL, not LCL.
With that in mind and considering the context i guess you meant LCL.
Now, LCL would be very hard to port to C++ because it is really built around Object Pascal features like a rich RTTI with explicitly exported properties, component streaming, "default" accessors, enums, sets, object instance method pointers and other features that C++ does not support at a language level. In C++ Builder the VCL is written in Object Pascal (and it even includes a Pascal compiler and linker), the language has been extended considerably to support Object Pascal-isms (e.g. __published section in classes, __property declarations, __fastcall calling convention that is Delphi-compatible, __delegate types for pointers to object instance methods, etc) and the runtime and library are written with some internal representation in mind (e.g. Pascal sets and strings are exposed to C++ using classes that have the same memory layout as the values the Pascal compiler creates). Of course some of those could be avoided if you do not care about a 1-to-1 port of FCL/LCL and compatibility with it, but still a lot of the functionality comes out of core Object Pascal features (since Borland had full control of the language, they designed both the language and API to complement each other, which is why it feels so weird in C++ Builder).
Beyond that, you'd really need an IDE with a visual designer like Lazarus as the entire API is designed to be manipulated in a visual way (e.g. while LCL does provide Qt/Gtk/Java/etc layout managers, they are really an afterthought in case you really want them and layout is mainly handled via anchors which have a dedicated visual editor - similarly the API uses a lot of custom collections that are meant to be edited with collection-specific editors in the IDE).
You could use Lazarus for that, but since Lazarus is meant to work with Free Pascal and does a lot of parsing (it essentially keeps the entire codebase, including all units and libraries as parsed nodes in memory) and automatic code editing (e.g. filling in the handler methods when you double click an event handler - or a component which fills the default event handler, navigating around the code, refactoring, removing empty handler methods, etc) you'll need to teach it enough C++ to be similar to writing a C++ compiler.
You could avoid the "porting to C++" part and using FCL/LCL directly from C++ in a similar way to what C++ Builder does... but then you'd need to convince some C++ compiler to include C++ Builder-like extensions and Free Pascal's developers to cooperate with said compiler's developers to ensure compatibility. You'd still need the Lazarus-needs-to-learn-C++ par though.
You could avoid all the above by making an "LCL inspired" (really, VCL inspired) library which vaguely resembles LCL for those who already know it but sticks with C++'s strengths. It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has.
Ah btw, did i mention the part where since LCL is essentially a cross-platform VCL reimplementation and VCL was designed only with Windows in mind, it has to implement a small subset of the Windows API for every platform and widgetset it supports? Yeah, are you sure you want to port that part too?
Honestly i'd love to see C++ Builder-like support in Lazarus and LCL, but practically i think it would be easier to make a new C++ Builder-like tool from scratch than make Lazarus, LCL, Clang (or GCC) and Free Pascal work together - even if we ignore the social/political side of convincing the developers behind those projects to work with the other projects.
C++ Builder had all those language extensions because it wanted to be binary compatible with Delphi units, including VCL. This is not the goal here.
If you don't care about that, most of the things that you've listed can be mapped to modern C++ just fine, with std::string for strings, std::function for function pointers etc. In fact, that's an advantage of starting with a higher-level API - because it has things like properties explicitly, they can be mapped to different languages in different ways, including cases where the mapping is one-to-many - e.g. property to a pair of method overloads in C++.
This all could be driven by a code generator, which would also produce the data structures to drive RTTI. Think about WinRT - single ABI and object model, multiple language mappings from JS to VB to C++. Delphi object model is actually somewhat similar to that, and even simpler in some ways (e.g. no refcounting). For a Delphi library mapped to C++, the end result could look a lot like C++/WinRT.
IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal.
As far as legacy warts, well, the only other framework we currently have that uses native widgets everywhere is wxWidgets, and its design was originally influenced by MFC of all things, so... It would be nice to have a clean ground-up design for modern idiomatic C++, and accounting for all the modern desktop platforms - but it's a huge project, and unlikely to get far because of that. LCL, on the other hand, is already there, and is a proven and maintained codebase. If there's a way to take it and produce a C++ version, or even a C++ bridge to a Pascal implementation (given that FP can statically link, it could all be in a single shared library that exposes a C API, and its clients wouldn't even know that it's written in Pascal).
Yes, i already mentioned all that with <<You could avoid all the above by making an "LCL inspired" (really, VCL inspired) library which vaguely resembles LCL for those who already know it but sticks with C++'s strengths.>>
However,
> IDE support is tricky, yes. You really, really don't want to constantly parse/generate C++, there's just too many corner cases. But if you just take the form designer, it doesn't need to know anything about code
...as i also wrote, <<It wont be LCL/VCL though and wont take advantage of Lazarus, at which point you might as well make something that avoids the warts that LCL/Lazarus has.>>.
Lazarus and LCL (and Delphi and VCL) strength comes from both being designed with each other and the language in mind and a big part of the process is for the IDE to be able to understand the language and modify the code as you work with the visual tools. These weren't designed in isolation as independent components, they were meant to be one thing.
What you describe here:
> But if you just take the form designer, it doesn't need to know anything about code - it just needs to understand components and properties, and spit out some representation that a code generator (or even a runtime loader) can turn into an actual object graph. That should suffice for layouts. Event handlers would have to be wired from code, but that's not a big deal.
...is really what wxFormBuilder, Qt Creator and even Gtk's Glade do and significantly inferior to the experience of using Lazarus. Hell, it is significantly inferior to using something like Delphi or Borland C++ Builder from the mid-90s. In Delphi 1 (that is Windows 3.1 time) if you drop a button in a form and double click it, the IDE will generate a new method for you, update the class declaration to include that method (at the correct place), write the method body, associate the OnClick event with that method and focus the code editor window with the text editor cursor placed on an empty line between the method's "begin" and "end" keyword so you can start typing code right away. If you decide that this was a mistake, you simply leave it empty and once you save the file, the IDE will remove the method (and any other empty handler method), update the class declaration and remove the event association as if nothing happened.
What you write here with "Event handlers would have to be wired from code" is already making the tool you describe a worse user experience than a tool released almost 25 years ago. And "that's not a big deal"? Every time i have to wire events by hand manually at work where we use Qt (the supposedly "modern" toolkit), where i have to declare the handler methods (slots) in the class and write their bodies in the source file, ensure that the signature is the same as what the event expects, write the correct bindings in the class initialization and all that by hand, i'm thinking how much of that is a waste of time since with Lazarus that would be a double click on the event's name in the object inspector and the IDE would do all that manual labor for me.
No, trying to separate the IDE from the language and the API is going to produce a much worse experience. It doesn't matter much if you want to make that hypothetical C++ library compatible with Lazarus and FCL/LCL (i only mentioned that because it would be something one could think to take advantage of all the work the FCL and LCL developers have made - FCL is almost as old as Delphi and LCL is only a few years younger, both providing a rich framework after all). You can create a fresh C++-centric API that understands there are more platforms than Windows and takes advantage of C++ features found in most modern compilers.
But if you want to make something like Lazarus and LCL the IDE must understand the language, it must be able to update and work with your code, it must be designed with the API in mind and the API designed with the IDE in mind. You must consider the entire thing as a whole, not just in parts.
If anything, some of the issues i have with Lazarus in terms of user experience come from Lazarus and Free Pascal being two separate projects made by two separate teams.
I don't strongly disagree with any of this. But again - we don't exactly have better options in C++, and especially not if you want native platform widgets. That is the baseline you should compare it to, not the experience of Delphi developers.
Creating a fresh C++-centric API is much harder than it sounds, and maintaining it over time, even more so. Go to any old online catalog that covers programming libraries, and look in its section for C++ UI stuff. There's scores of dead frameworks there that nobody has heard about. I don't see why it would be any different today with any project of that scope - so the only hope is to reduce the scope.
I agree that it is hard, both of my posts where about why it is hard to make something like LCL - be it exposing it to C++, making a direct port or making something inspired by it. However what you describe (which i assume was about "reducing the scope") isn't any different from what Qt and wxWidgets already do, especially on the design side (where LCL and Lazarus shine and is their main attraction). If you are going for something that is already sub-par (ie. worse than Lazarus) and doesn't even provide something better than existing solutions, why bother?
wxWidgets does, but I think even an automated conversion of LCL API would be better than what they have. It's a framework that's still stuck in C++ circa mid-90s.
I'm talking in the context of working with the framework, not how the widgets are implemented. When i write "Qt and wxWidgets already do" it should be obvious i refer to something they both share, not something they differ. There are many differences in how all the mentioned frameworks, there isn't a point of comparing them down to that detail.
FWIW the majority of LCL is also designed in the mid-90s as it is really a clone of VCL which was designed with Windows in mind and has a lot of Windows-isms (e.g. TColor is 24bit only, no alpha channel, the extra byte is used - like with Windows - to encode a pseudocolor to be translated in one of user-defined colors ... from back when Windows allowed users to modify the color palette, but anyway).
IDE and visual form layout editors require specialized property editors. And amount of code for design time support is significant usually.
Yet, data produced by layout editors is not DIFF friendly. Ability to edit UI definitions in text forms is valuable for collaborative work. That's why Delphi/Lazarus is popular among INDIE developers but not in large companies.
I'm not sure what you have in mind, Lazarus (and AFAIK Delphi at least since version 7, most likely earlier too) saves the form as a text file which you can diff and i do that all the time when looking at changes in my code before submitting them. In fact the format is very readable and has a syntax like:
object ScriptConsole: TScriptConsole
Left = 349
Height = 331
Top = 710
Width = 487
...
object Cmd: TEdit
Align = alBottom
end
...
end
(this is part of the code from a form of a project of mine called ScriptConsole)
It only stores properties changed from their defaults which makes for very compact files and focusing on the stuff you have actually worked on.
If anything i find the XML files that other tools (like Qt Designer and wxFormBuilder) use harder to read.
It's also true that the API is weird, and some of the wrapped native APIS are deprecated, or work weirdly with modern features.
Now if the qt branch for Linux was stable...
But really, C++ has so much choice compared to say, Rust.