You can sign up to get a daily email of our articles, see the Mailing List page.
Favourite Linux IDE?
Page: «8/9»
  Go to:
edo 7 May, 2019
visual studio code is very cool
Cedron 11 May, 2019
Generally, on Linux, my "IDE" has been a text editor and a command line. I try to format my code clearly enough so that syntax highlighting is unnecessary. I realize that many people programming are younger and have known nothing but color coded editting. That's progress, I guess.

Earlier this year I found the Gambas. Gambas is a VB like, but vastly improved, IDE for developing desktop applications (or command line) in Linux. Since VB6 has always been my favorite programming environment, finding Gambas was way overdue, and a very pleasant surprise. I don't know why I hadn't found it before, it has been around for quite some while and is fairly mature.

It is not really a game development platform, though I am using it as such, in a sense. (If anybody wants a shared library for gamepad input, let me know, I wrote one.)

If you are interested, I suggest you start with the sample programs I posted on a Gambas forum:

"Programming is supposed to be fun" at https://forum.gambas.one/viewtopic.php?f=4&t=674

Ever seen a scrollbar act like a cannon with recoil? You'll find it in the second example.

PPA: gambas-team/gambas3

The latest version is 13.0

A very helpful website is: http://gambaswiki.org/wiki

It is absolutely the best IDE for learning how to program I know of. The nice thing is you will never "outgrow" it. It is a byte code interpreter though (but so is Java and Python, excepting JIT which Gambas has too). It is really easy to call C .so libraries, so anything computationally heavy can also be tackled.

It is Linux specific, but it is supposed to work on Raspberry Pi.

Ced
tuubi 11 May, 2019
Quoting: CedronGenerally, on Linux, my "IDE" has been a text editor and a command line. I try to format my code clearly enough so that syntax highlighting is unnecessary. I realize that many people programming are younger and have known nothing but color coded editting.
Modern text editor features like syntax highlighting make even the nicest code quicker to skim and parse. And a proper IDE can help you work faster and avoid mistakes, no matter how old you are. Their features are even more helpful if you often work on code someone else wrote, like many of us do at work. And the helpfulness is proportionate to the size of the code base.

Quoting: CedronThat's progress, I guess.
Indeed it is.
ageres 11 May, 2019
What's wrong with highlighting? It helps reading and navigating. It has been used since the first colour displays. You must be a dinosaur if your first computer was monochrome. I was introduced to the amazing world of programming by Turbo Pascal in Windows 98 which looked like this:


(Actually, when I was in elementary school, there were Yamaha MSX-based computers with one-colour displays, high school students used them for studying BASIC, but I never had a chance to use them.)
Cedron 11 May, 2019
"Monitor? You have a monitor?" he asks incredulously as he plays 52 card pick up with his punch cards.

Don't get me wrong. I like syntax highlighting a lot. The point I am making is that it is sort of a crutch for improving code readability (and it does improve readability tremendously). Thus, if that is all you are used to, then formatting your code to be readable when displayed in monochrome is not a consideration that is in the forefront in your mind, if even at all.

On the other hand, if your code is very readable in monochrome, it is even more readable in technocolor.

I.e., IDEs can make you lazy and sloppy.

I like code completion as well. It saves a lot of copying and pasting (no, you shouldn't retype variable names, this practice only encourages cryptic naming conventions, though cryptic names are okay for local variables).

How about procedure separators? Most IDEs provide them. I turn them off. Instead, I put a comment line in like thus:

//=================================================================

That way it is part of the source file and is there no matter which context it is viewed in. As in the first example in the forum post I linked above.

Ced
monnef 11 Jul, 2019
I am a big fan of IDEs from JetBrains (but not blind, I did try Atom, Sublime, VSCode, Eclipse, Visual Studio and a few more obscure ones).

At work I am using IntelliJ IDEA for JavaScript, TypeScript, CSS, Sass, SCSS, HTML.

When working on games I tried CLion (Godot) and now I will be probably using Rider (Unity). Currently I am working on a small platformer game in Godot, using GDScript so the IDE is Godot's editor and I miss a lot of functionality from IDEA (that's one reason I am planning on going to Unity and C#, because in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).

For other projects I use IntelliJ IDEA usually for Haskell, now trying ReasonML for front-end needs for which Haskell, or rather its tooling, is very far from ideal.

It would take me a long time and my productivity would take a giant hit, if I would have to use feature-less editor instead of a proper IDE. For example type-aware autocompletion is priceless.
Pangaea 12 Jul, 2019
Quoting: BlackBloodRumPersonally, I now prefer "Geany" simply because it is fast and lightweight and "just works" I used to love Eclipse but release after release it just felt heavier, slower and slower in the end I ditched it and went Geany. Honestly best decision I ever made!

Low-pro here. Started fiddling about with XML, CSS and wikitext again, and re-discovered Geany in the Software manager. It's an excellent little piece of software -- even if it isn't a proper IDE (?). Does all I need, and better than online highlighting, and of course the Text Editor.

Light-weight, and "it just works".


(Back in the Windows days, Notepad++ was the go-to.)
PrivacyParanoid 12 Jul, 2019
I love JetBrain products. They're so refined and customizable that i cannot use anything else anymore. I don't mind the proprietary approach used for the Ultimate version and the *Storm/*Charm versions since i care about open computing mostly when it comes to the platform (OS) and not the final applications.
tuubi 12 Jul, 2019
Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).
I'll take your word for GDNative, but didn't Godot get C# support in 3.0?
monnef 12 Jul, 2019
Quoting: tuubi
Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).
I'll take your word for GDNative, but didn't Godot get C# support in 3.0?

Yes, docs for C# are better - well, at least some exist and API is more closer to GDScript, so separate docs for everything are not needed. For GDNative (C++) it, all documentation, was literally one page on wiki which described basic setup with example which didn't work (didn't even compile). There are many differences between C++ and GDScript API, e.g. different types, custom memory management which isn't documented (Godot team is ignoring current C++ features which implement mostly same thing), code within C++ API (bindings) is undocumented too. It was a nightmare to use - if you are not familiar with Godot internals, do yourself a favor and avoid GDNative (with C++) at all costs.

When I was briefly testing C# with Godot, there were some significant downsides - for example missing stack traces after crash, broken project file for C# which had to be manually fixed, more boilerplate compared to GDScript, issues with custom C# types (IIRC struct isn't supported at all = performance problem or use a lot less readable solution), undocumented differences in API compared to GDScript (worst were conversion rules between C# types and GDScript ones, it is not a smooth experience). Performance-wise C# isn't bad (much better than GDScript), but marshalling (converting data between C# and GDScript) is very costly and one has to be careful about memory management (GC). I don't like very much how a lot of things in Godot API is "stringy", it really undermines static typing of C# (and C++).

Simply put, Godot supports GDScript well, nothing else, even though they claim C# and GDNative (C++) are officially supported. One of reasons why I am going back to Unity is because I want to write in a language which is properly supported by the engine, its team and community (by supported I don't only mean technical side, but also docs, guides, tutorials, community, marketplace). Unity is just so much more mature.

For my use-case was quite important debug view which Godot misses (viewing real 2D/3D instances in editor when game is running). Another thing I don't really like is that a node can only hold one script (forcing deep branches in a node tree), cumbersome addressing of these inner nodes, difficult refactoring, missing inheritance or any equivalent mechanism. With Godot I picked C++ because of performance, but it might be possible to reach similar performance in Unity with C# using their custom compiler (so I could write in a reasonably nice language - C#, C++ is for me too low level, unnecessarily complex and wordy). Maybe in a few years I'll try Godot again (after 3D supports basic features like occlusion culling and unlimited number of lights).
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.