Show HN: LeanCreator – a stripped-down QtCreator for C/C++, LeanQt and BUSY

https://github.com/rochus-keller/LeanCreator

by Rochus • 3 years ago

111 64 3 years ago

ur-whale2• 3 years ago

Edit and continue supported?

Rochus25• 3 years ago

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-whale2• 3 years ago

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.

jenadine• 3 years ago

Any plan to support LSP to work with more programming languages? Or is the plan to focus on C++ only?

Kelteseth• 3 years ago

I really dont get this project. If you want LSP support just use regular QtCreator.

Conscat• 3 years ago

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.

Rochus25• 3 years ago

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.

humanrebar2• 3 years ago

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//

codazoda• 3 years ago

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.

Rochus25• 3 years ago

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.

bitwize2• 3 years ago

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.

hermitcrab2• 3 years ago

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'.

Brian_K_White• 3 years ago

"I kicked out all stuff I never touched during the last twenty years."

A fine and eminently defensible filter.

AshamedCaptain• 3 years ago

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.

Rochus25• 3 years ago

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• 3 years ago

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?

pixelesque• 3 years ago

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• 3 years ago

Why not KDevelop?

glitchc• 3 years ago

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.

Rochus25• 3 years ago

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.

simplotek7• 3 years ago

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.

EStudley• 3 years ago

Why no QML support? Interested in OP's decisions there. Would it just bring in too much bloat?

Rochus25• 3 years ago

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.

Show HN: LeanCreator – a stripped-down QtCreator for C/C++, LeanQt and BUSY

Related Stories