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 fo

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.