certainly speaks to a profound lack of understanding of basics. imagine the ux choices an organization like that would make, if they can't think to highlight a screenshot in an accessible manner of something that's intrinsically a visual product
Meta: This is also a testament to how learning is often incidental. Like I read the comments on this thread and go to another thread for far manager and bam screenshots link on the top right corner.
you get what you pay for? the gripe with the ux is more a wxWidgets issue than a CodeLite issue. IMHO. It does what it claims it does. It doesn't waste cycles on making things pretty, but rather making things functional. Granted, I do wish devs would take some extra time on ux and colors, in this case though - it's out of scope.
However, I do see they support some VSCode themes so maybe in the future the UI could get some love. If you're used to vim and/or unix c/c++ development, you probably don't care - target audience of CodeLite.
I used codelite as my primary IDE for years, and was generally very happy with it. In the end I switched to VSCodium + mingw32 + cmake because some of the libraries I needed wouldn't build on TDM-GCC any more and I wanted to get back onto a more mainstream gcc build.
As all IDEs do, it started out very lightweight and snappy, and then gradually got heavier and slower as it gained more features. It's still top tier IMO though.
Yeah, it feels a bit like back in the day when every janky adware installed a browser toolbar and your relative would ask why the Internet was so hard to read.
Looking at the repo, it doesn't look very "light", and it's difficult to think about an IDE that is possibly light, especially when it supports C++/php/rust/nodejs.
Is it possible to know what companies use it? It has 80 contributors on github, but 121 issues for such a large seems a bit low. Not trying to ruin the mood, as it seems to use nice tech like a language server, ctags, etc.
Personally I only like IDE because it's easier to debug with them, but they're often just big monsters that are difficult to use or make sense of, and they often require a fast computer.
I prefer the "light minimal software" approach, where I just write things I need without going too big.
The author started out making a library that does auto-complete based on SQLite table definitions, which is where the etymology of the 'lite' in 'CodeLite' comes from. Not 'lite' as in: "This IDE is lightweight".
Still a weird and probably unfortunate name. But now you know.
> and they often require a fast computer.
About 10 years ago this argument ceased to hold much relevance. Or, at least, it did for all IDEs I've investigated. The complexity of editing a sack of code, CPU-wise, hasn't changed all that much, and 10 years has had quite the impact on how cheap 'hardware that can run IDEs without breaking a sweat' has gotten.
> difficult to use or make sense of
Writing software is inherently complicated, and many complicated tasks are significantly helped with the use of complex tools that require a significant investment to learn to use properly. The answer isn't to resort to building tables using a simple handcrafted hammer and a manual saw because those things are 'easy to understand'.
> I prefer the "light minimal software" approach, where I just write things I need without going too big.
To channel Einstein a bit - tools should be as minimal as possible but not _more_ minimal. Which mostly just kicks the can down the road: I don't think it's useful or correct to claim that IDE fans "just like pointless complexity and fail to appreciate the elegance of simple tools". They just defined "minimal" differently from you.
> About 10 years ago this argument ceased to hold much relevance. Or, at least, it did for all IDEs I've investigated. The complexity of editing a sack of code, CPU-wise, hasn't changed all that much, and 10 years has had quite the impact on how cheap 'hardware that can run IDEs without breaking a sweat' has gotten.
I really disagree here. Building C++ software with visual studio takes ages, its auto completion feature breaks VERY OFTEN, and after enabling C++20 for a Qt project, compilation times were 3 times longer.
I've recently started using Lapce (https://lapce.dev/) as a sort of barebones VSCode alternative and I find it nice for the hobbyist use case. It integrates with all the things I need, and other less mature features I bypass completely (I prefer to do Git from the terminal anyway).
I used this years ago, last I looked it was very similar to Codeblocks. So much so that they share use of WXWidgets and Scintilla.
I’ve since gone to Visual Studio and VSCode and never looked back. I never saw the appeal to these outside of beginner use. Plus I have yet to find a debugger that beats visual studio’s.
> I think most Linux c/c++ devs just do everything without a debugger and use emacs and vim instead
They often use gdb or some sort of front end. I learned gdb in a college Unix course and found it to be a pain. But I’m sure like all things with unix commands, once I figured out what I want for daily use it would become more comfortable.
I'll admit I seldom make use of debuggers. Strangely I feel more productive with good old "printf debugging" than using fancy debuggers.
I think it is more just a habit at this point and has the beauty of working just about everywhere within every toolset, versus learning how to use each language and IDE's debugging functionality.
The benefit of debuggers is that you can run experiments on your program while it's running. You don't have to stop, add a new print, recompile, re-run, and do whatever steps were required to get to the point of the printf. As you inspect the data, you can further ask more questions of your program without having to start all over again.
These days, I refuse to start a new language if there is no debugger or IDE available for it. I did that in C using an Ubuntu server with only vim and makefiles all through college, and I'm never going back to that.
I tried web assembly the other day. I couldn't get a decent debugger environment running on it, so I abandoned it.
Which is especially strange since they are already on GitHub, which means if they attached those artifacts to the GitHub Release <https://github.com/eranif/codelite/releases/tag/17.0.0> then they'd be served to you from S3 at "S3-speeds"
I mean, I hear them about "donationware" or whatever that is, but even having support.php hotlink to the GH release artifact would still be a win, and security through obscurity means likely folks wouldn't look on the GH releases page for the artifacts to bypass the support.php nagware anyway
