I'm curious if it might make sense to port FCL (FreePascal / Lazarus take on VCL replacement) to C++.
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.
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.
object ScriptConsole: TScriptConsole
Left = 349
Height = 331
Top = 710
Width = 487
...
object Cmd: TEdit
Align = alBottom
end
...
end
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.
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).
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.
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.
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.
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).