[HN Gopher] Show HN: LeanCreator - a stripped-down QtCreator for...
___________________________________________________________________
Show HN: LeanCreator - a stripped-down QtCreator for C/C++, LeanQt
and BUSY
Author : Rochus
Score : 92 points
Date : 2023-02-25 13:49 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| EStudley wrote:
| Why no QML support? Interested in OP's decisions there. Would it
| just bring in too much bloat?
| turbobooster wrote:
| Just use flutter...
| freedomben wrote:
| "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.
| marsven_422 wrote:
| Love to but it doesn't support 32bit ARM
| Conscat wrote:
| 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?
| lockhouse wrote:
| Aren't they different use cases for the most part?
|
| Qt is good for cross platform _desktop_ software, but very
| clunky for mobile.
|
| Flutter is good for cross platform _mobile_ software, but very
| clunky for desktop.
| Rochus wrote:
| Agree; that's one reason why LeanQt doesn't support QML at
| all.
| Kelteseth wrote:
| Qt is fine on mobile and desktop if you are using qml.
| tpush wrote:
| What's the best mobile app made with Qt?
| ghosty141 wrote:
| 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.
| ur-whale wrote:
| Edit and continue supported?
| Rochus wrote:
| 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.
| ur-whale wrote:
| > I suppose you mean editing source code during a debug
| session and continue with the new version of the compiled
| code
|
| 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.
| Rochus wrote:
| 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.
| glitchc wrote:
| 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.
| Rochus wrote:
| 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.
| jenadine wrote:
| Any plan to support LSP to work with more programming languages?
| Or is the plan to focus on C++ only?
| Rochus wrote:
| 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.
| humanrebar wrote:
| The Debug Adapter Protocol might be interesting for similar
| reasons as the Language Server Protocol if you haven't seen
| it yet:
|
| https://microsoft.github.io/debug-adapter-protocol//
| Rochus wrote:
| It's a good idea but most debuggers I'm confronted with
| don't support it (i.e. only their future versions support
| it).
| humanrebar wrote:
| I'd be interested in a breakdown on how useful (in terms
| of functionality) and easy support for DAP is, from
| either side of the protocol.
| Kelteseth wrote:
| I really dont get this project. If you want LSP support just
| use regular QtCreator.
| Conscat wrote:
| 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.
| sho_hn wrote:
| > 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.
| AshamedCaptain wrote:
| 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.
| Rochus wrote:
| > _the internal C++ parser limitations, e.g. poor 'auto'
| support_
|
| 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.
| arka2147483647 wrote:
| I have read somewhere that it would be possible to use
| libclang to parse C++. I have no experience on this, but
| perhaps you should look into it?
| Rochus wrote:
| 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).
| pixelesque wrote:
| 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.
| zerr wrote:
| Why not KDevelop?
| codazoda wrote:
| 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.
| hummus_bae wrote:
| [dead]
| Rochus wrote:
| 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.
| bitwize wrote:
| 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.
| marssaxman wrote:
| 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.
| jcelerier wrote:
| https://www.jetbrains.com/lp/devecosystem-2022/cpp/
|
| 57% use cmake, next most used build system is make at 33%
| Rochus wrote:
| 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.
| Rochus wrote:
| 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.
| elcritch wrote:
| Oh cmake is full of so many gotchas. Dynamically typed
| specification languages are so painful.
|
| 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) + "\""
|
| 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.
|
| 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.
| Rochus wrote:
| Thanks, I appreciate.
|
| > _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).
| elcritch wrote:
| > 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.
| doodlesdev wrote:
| 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.
| Rochus wrote:
| 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.
| andai wrote:
| 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.
| Rochus wrote:
| 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.
| AbusiveHNAdmin wrote:
| [dead]
| johnny22 wrote:
| even qt left qmake behind in favor of cmake, so you're
| not the only one :)
| Rochus wrote:
| 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.
| AbusiveHNAdmin wrote:
| [dead]
| hermitcrab wrote:
| 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'.
| Rochus wrote:
| 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' ;-)
| hermitcrab wrote:
| I'm solo developer, so I haven't run into that. Do you
| mean it is slow to modify a qmake file with subdirs, or
| slow for qmake to evaluate it?
| Rochus wrote:
| 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.
___________________________________________________________________
(page generated 2023-02-25 23:01 UTC)