It's a sad story about the state of Qt Creator's plugin API.
In any case, I kind of agree with the author here that QtCreator basically peaked in both usability and performance somewhere around Qt Creator 3.4 . I would even say 3.3 since that's when it could no longer be built with Qt 4.
The biggest problem with such older versions of QtCreator is however the internal C++ parser limitations, e.g. poor 'auto' support. The outdated C++ parser is the main reason I had to stop using old QtC -- at some point, the parsing is so bad that Find Usages stops being reliable. Any clang based replacement is just 100x slower and tends to have even worse support of recovering from parse errors than the internal parser.
I ponder what the author's using -- I can't guess from the screenshots.
Yes, there is even a clang plugin which I could migrate, but it - of course - requires clang and llvm, which is big and not particularly fast (as noted by
AshamedCaptain).
I agree too on the peak being 3.3 or so - I'm still using 3.3.2 on my Intel Linux machines - unfortunately on my main new AMD machine I had to move to newer versions due to core plugin crashes in older versions in order to get it to run, and the Build Kit infrastructure is just a mess there IMO (I know it was added to allow flexibility, but I never needed that functionality, I wanted one debug build for use in an IDE, and I'd build release / deploy stuff outside of the IDE).
The main annoyance I had with older QtCreator versions was that you couldn't actually text edit CMakeLists.txt files in the editor, it would treat them as Project files regardless of how you tried to open them, so had to use an external editor for those files, which seems a bit silly.
It's been my main C++ dev IDE since 2010, but I'm starting to think about moving to VSCode, but not really happy with that either for editing (in either C/C++ or Rust with RustAnalyzer, but I find it good for Python and JS): auto-indent is very primitive and rarely does the right thing, and tooltip popups for hints and errors just seem random and inconsistent to me. It's functional though, but I wouldn't say great compared to my QtCreator experience of just very fluently typing out large amounts of code the way I want it.
This readme could use a definition for those of us that don’t know qt creator. Here’s what I think it might be after reading half of this doc.
LeanCreator is a lean cross-platform integrated development environment (IDE) based on Qt Creator but stripped down to a single file, easy to build, light weight executable with no external dependencies.
That's one part of the story; LeanCreator is rather "derived from" than "based on" QtCreator, because there was a lot of refactoring and redesign; it's also important to note that it uses the BUSY build system which is fully integrated with the IDE with semantic navigationt through the build specification files (instead of qmake, see https://github.com/rochus-keller/busy); and with "stripped-down" and "lean" I mean that I kicked out all stuff I never touched during the last twenty years.
I thought the modern C and C++ communities effectively standardized on CMake? I've never heard of BUSY before this, and I'm dreading the "now there are 14 competing standards" implications.
I'm no longer interested in cmake or any other dynamically typed build specification language (actually an old-fasioned, string-based scripting language in the case of cmake). I tried to like cmake for twenty years. Now I'm migrating all my projects to BUSY. I'm even leaving qmake behind because it essentially suffers from the same disadvantages than cmake. GN is a much superior build system (or meta build system, if you insist), but unfortunately it is also dynamically typed using glorified strings for all kinds of semantically significant stuff. I want to be able to statically check my build specification and profit of 60 years of programming language best practices, not to guess around and waste time with a specification language suitable for toy projects if at all. BUSY is not yet a standard, but it has the potential. There is enough room in the world for different standards on the same topic.
That'll break in annoying (possibly insecure) ways and is tedious to write the quotes. Perhaps you could add a 'quotedString' proc? Maybe:
""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir)
Speaking of standards, have you tried talking with any cmake collaborators? I recall reading a post on HN discussing a possible new cmake frontend language. Something like BUSY as a frontend could be cool.
It may look a bit complicated at first, but the underlying syntax rules are surprisingly simple and consistent. There are only a few small macros for convenience like the 'list' one that replaces array syntax. Best of all that means I get all the goodies of a statically typed language like type annotations from the LSP.
> it looks like you're quoting a shell string like:
That's not particularly a shell string, but a DEFINE; the rule is to declare them as they are required by the compiler command line of a given platform. I can add a quoted_string() predeclared procedure if it helps.
> have you tried talking with any cmake collaborators ... Something like BUSY as a frontend could be cool.
No, I haven't; the BUSY spec is open source and available if need be, but for one part I would be very surprised if it was used just as is for the mentioned purpose, and on the other part I'm not sure whether it is a decent approach to add yet another layer to cmake (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, increasing the confusion we already have).
> That's not particularly a shell string, but a DEFINE
Ah I am guessing that you are invoking the compiler using ‘sh’ (or cmd.exe on win). Otherwise you wouldn’t need the extra quotes. But then you should properly quote for the posix shell.
Though you could exec the compiler but then you could probably keep it as a list.
> I'm not sure whether it is a decent approach to add yet another layer to cmake
Yah that’s the problem. Especially with large legacy build systems.
> (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility,
Well I think they meant it’d built on the c++ layer. But it’d still need the old cmake language parser still.
This statement alone automatically eliminates any credibility from what you said. CMake was revolutionized with CMake 3.0, which was released in 2014. Since then CMake became a radically different build system, and got so many things right it became the de facto standard.
Also, CMake is a build system generator. It's just a high level specification that generates build systems that you pick, like make, ninja, even visual studio and Xcode.
I started to use it when I used VTK in the early 2000; I closely followed all of its lifecycles, including all pipe dreams; and thank you so much for teaching me about build systems.
What about Meson? Apart from CMake it's the build system I've seen the most recently. Personally enjoy it a lot. Popularity of tools at least for me is always a consideration since it means it's easier to get help from other people or assemble a team of contributors to a project.
Meson did indeed some things better than cmake, and I seriously evaluated and considered it for my projects; but on the other hand it's still a dynamic language and has quite some peculiarities, and after analyzing many projects using Meson, where people have used work-arounds against the intent of the language, I decided to come up with my own proposal. Meson also depends on Python which hinders ab initio bootstrap (a major goal of BUSY), and the non-Python versions are not fully compatible or not cross-platform.
Not sure if this is the right place to mention this, but the Python keyword activated my neurons: upon running LeanCreator.exe I was greeted with two error boxes:
lldb-vscode.exe - System Error: The code execution cannot proceed because python310.dll was not found.
lldb.exe - System Error: The code execution cannot proceed because python310.dll was not found.
This occurs every time the program is run, though the program does indeed start, although I haven't been able to test it much since I'm not very familiar with Qt and Qt Creator.
Edit: I'm trying to create a Hello World. File> New File Or Project only lets me "import" one, so I "imported" an empty folder. Nothing seems to happen in the UI (there is no indication that a project has been created or opened, projects button is greyed out, and I can't find a way to add cpp files), though it did create a bunch of project files in that folder.
The file and project wizzard is on the todo list (see readme); I recommend you download e.g. the LeanQt source and open the top-level BUSY file with LeanCreator to experiment.
Concerning "lldb-vscode.exe": I never saw this and don't know what it means; maybe LeanCreator has found an Clang/Lldb installation somewhere which is compiled with Python support, but Python is not in the path; it's possible that you get this error on start because LeanCreator tries to get information about the toolchains it finds by running the programs; you likely get rid of this error if you put the Python executable in the PATH before starting LeanCreator.
So I indeed got the same error when running lldb, so I upgraded my llvm from 14 to 15*. This did not solve the error, so I installed Python 3.10 and put it on the path. Now launching LeanCreator takes 26 seconds (nothing appears to happen, so I thought it was broken, but after a long time the window appears) but there are no error boxes anymore.
Edit: followed your suggestion.
01:59:38: Running steps for project LeanQt...
Error while building/deploying project LeanQt (kit: Desktop)
When executing step "Busy Build"
Oops, that's not a good trade-off; does it always take that long when you start LeanCreator on your machine, or was it - as I would expect - only the first time it required to locate the debugger? If it repeats with each start I should add an option to disable this search or reduce the timeout. Can you try whether it also takes that long if you directly start lldb on the command line?
Ok, I see, but apparently LeanCreator hangs when accessing your toolchain and consequently also cannot use it to build anything; either there is an installation issue with the toolchain or an incompatibility with LeanCreator which I don't know yet. The 30 secs are probably the timeout in LeanCreator when trying to run an executable of the toolchain. Which version of Clang/lldb have you installed? Have you also MSVC or MingW installed on your machine?
Maybe there is compatibility issue with lldb; I already found an issue with the recent lldb version on Mac M1 (see https://github.com/rochus-keller/LeanCreator/issues/1). You could try to tempoarily rename the clang/lldb directory so LeanCreator doesn't see it anymore at startup.
A toy such as... DXVK, elementaryOS, Geary, GTK, almost any GNOME application, GStreamer, i3, libfuse, libcamera, Mesa, MPV, Cisco's OpenH264, PipeWire, PostgreSQL, Qemu, SciPy or systemd? I guess our definitions of what's a toy are different :)
Yes, unfortunately they decided to replace one antiquated technology by yet another one. It's a pity that QtC didn't come up with something much better and just adopted cmake instead.
> Yes, unfortunately they decided to replace one antiquated technology by yet another one.
Your statement makes no sense and reads like you have an irrational axe to grind regarding cmake.
CMake is just a way t provide high level descriptions of your project and from that generate a build system of your choosing. It does its job well and better than any alternative. Making random claims like "outdated" is meaningless, specially as you can use cmake to generate Ninja or visual studio projects.
There have always been 14 competing standards. It does seem like CMake has grown somewhat more popular in the last couple of years, but standardized would be a stretch.
57% of the people willing to respond; this information is as useful as "Rust is the most beloved language" in Stackoverflow polls. Maybe it's true, maybe not.
Not really. You are the one claiming that a survey is not statistically representative, and based on that baseless assertion you proceed to argue the exact opposite without any proof or reason.
I've been using qmake for >20 years. Its good enough for my purposes. I have no plan to switch to cmake or any other build system, unless I have to. But I am also using Subversion, so I am not one of the 'cool kids'.
Same here in principle; the problems start when you have big project which require qmake SUBDIRS and the like; it's ugly and very slow. I'm neither one of the 'cool kids' ;-)
You can also easily run into that as a solo developer if you have a project with more than one target, e.g. an application with a few shared libraries (or e.g. Qt plugins).
> is slow to modify a qmake file with subdirs, or slow for qmake to evaluate it?
It's mostly slow because it generates a lot of make files which all have to be run to find out whether there is anything to do; you can e.g. try by generating the qmake project for LeanQt and open and run it in Qt Creator; then when everything is built make a change in one file and build; when you do the same with LeanCreator and BUSY you will notice that it's more than twenty times faster.
This looks great, but I am a bit dismayed by one "will not tackle" feature: qmake support.
Why make this call? Most qt projects default to qmake by default. Making this a will not tackle acts as a big barrier to anyone looking to port their projects over to LeanCreator.
I still use Qt Creator for my qmake projects until everything is migrated. It doesn't make sense to add qmake support to LeanCreator because Qt Creator is still available on all platforms and continues to support qmake (at least I have no other information). If people port their projects, they actually don't port to LeanCreator, but to the BUSY build system, which in turn can generate qmake projects in case you want/have to use Qt Creator for some tasks.
> It doesn't make sense to add qmake support to LeanCreator because Qt Creator is still available on all platforms and continues to support qmake (at least I have no other information).
This take sounds ridiculous. It's ok if you want to use the project to try to drive up the adoption of a build system, but it's absurd to argue against the adoption of a widely established build system by stating that people should instead use other IDEs.
QML and Qt Quick are mostly useful for mobile applications, but were barely able to prevail in this market. Qt originated as a desktop application framework. LeanQt aims at the original purpose and strength of Qt.
I will likely add support for my Oberon+ language and also migrate the Verilog and Lola plugins to LeanCreator. LSP support is not planned so far, because for each language also the toolchain must be supported including e.g. a decent debugger integration, which is far more effort than just parsing the language.
LSP support is considered a basic requirement for any modern code editor, but especially a C++ editor. If (respectfully) dinky TUI editors like Kakoune, Micro, and Helix have working LSP these days, it doesn't seem ridiculous to me to suppose that this might too.
> LSP support is considered a basic requirement for any modern code editor, but especially a C++ editor.
I'd say a C++ editor is by far the type of editor least in need of LSP support, given there's a lot of great C++ infra and integration that pre-dates LSP (e.g. using libclang directly, or even fully custom). It's relatively more the newer languages that went with LSP from the start or that are just too niche to get attention from IDE dev teams that benefit.
That said, LSP is a great idea for the ecosystem in general.
I suppose you mean editing source code during a debug session and continue with the new version of the compiled code from where the debugger was; no, that's completely out of scope and affects the whole toolchain, not only the IDE. But of course you can edit the values of variables in the debugger and continue with the new values.
I never used it on Windows and never missed it on Linux or Mac. And it's likely very complex to implemenent, and more the concern of the toolchain than the IDE. Anyway, LeanCreator does not support it; the focus is more on simplicity and cross-platform.
"Just throw out all the knowledge and experience you've gained in C++/Qt over the years (possibly decades) and use a completely different language and framework"
Not great advice IMHO.
Even for people new to both there are still compelling reasons to use Qt. Flutter looks great and I'm optimistic about the future, but it's still young and there are a lot of things it can't do.
Disagree, its a huge pain. Im working with Qt QML everyday building an HMI and getting the layouting etc right is really time consuming compared to any other framework Ive work with.
That's interesting, I didn't know that. Out of curiosity, what GUI development are you doing on 32bit ARM? Is it something to do with systems on a chip or vehicles UI?
In any case, I kind of agree with the author here that QtCreator basically peaked in both usability and performance somewhere around Qt Creator 3.4 . I would even say 3.3 since that's when it could no longer be built with Qt 4.
The biggest problem with such older versions of QtCreator is however the internal C++ parser limitations, e.g. poor 'auto' support. The outdated C++ parser is the main reason I had to stop using old QtC -- at some point, the parsing is so bad that Find Usages stops being reliable. Any clang based replacement is just 100x slower and tends to have even worse support of recovering from parse errors than the internal parser.
I ponder what the author's using -- I can't guess from the screenshots.