Show HN: LeanCreator – a stripped-down QtCreator for C/C++, LeanQt and BUSY
github.com
github.com
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.
I'm considering updating the internal C++ parser, which is written by Roberto Raggi, by a more recent version, but it's not my top priority.
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.
Also, project file formats, e.g. if you have .vsproj or .pro files you can't always just use another IDE.
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.
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.
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.
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"GCC 12.1.0 (MSYS2)
LLVM 15.0.7
MSVC 19.33.31630 (not on PATH)
(This thread's probably getting too long, you can reach me at my email address. See my HN profile.)
Take a look at a list of projects using Meson here: https://mesonbuild.com/Users.html
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.
BUSY looks cool! Unfortunately my work projects rely on another big C++ project that has its own meta cmake layer.
One thought, it looks like you're quoting a shell string like:
""NAPPGUI_BUILD_DIR=\"" + tostring(root_build_dir) + "\""
""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir)
BTW, here's my latest attempt to avoid dynamic configuration files by making a YAML like in Nim: https://github.com/elcritch/cimporter/blob/exper-interp/test...
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).
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.
Irrelevant. The whole point is that cmake 3.0, which was released in 2014, is an entirely different beast. See "modern cmake".
It makes no sense at all to argue thing about stuff just because you used something two decades ago. Totally irrational.
57% use cmake, next most used build system is make at 33%
Unless you have any data supporting your personal belief, it hardly sounds rational to try to reject objective data just because you don't like it.
Does this feel even remotely reasonable to you?
They have. You'll be hard pressed to find anything other than CMake on any professional project.
Even Qt has migrated to CMake in spire of having developed make.
This was the very first time I ever heard of BUSY, quite frankly.
> 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.
A fine and eminently defensible filter.
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.
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.
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.
Yes, correct.
That's something Visual C++ has been able to do for the past 20 years and the Linux ecosystem has never managed to catch up to.
It's unfortunate, because it's a really useful feature, especially when you build GUIs.