Linux Development, Pushing Forward

A few weeks on from questioning the viability of main stream Linux Development, and i have learnt much. I still feel that there are many hurdles for new-comers, but i finally feel confident that i can step over the next sets of hurdles. As with any new toolchain, the initial set up is the worst, from there on, it is relatively smooth sailing. And while there are certain aspects of the toolchain that are a complete mess, i turn again to Miguel de Icaza and the Mono team as a beacon of light in the quest to make Linux a step closer to the main stream.

KDE development is not enjoyable. Well, possibly this is a bit harsh. I very much did enjoy making something ( all i did was modify a widget at my wife's request ), but one of the reasons i enjoyed it so much is because i fought so hard to set up the development environment that once something was achieved, it felt like a miracle. First thing that was learnt ( and i've tried it 3 times, all with similar result ), was that development from trunk is not worth it. The amount of time spent just to make a particular set of the trunk ( perhaps a widget or application ) build, is enormous. What is much simpler, is using the KDE-Devel packages from your distribution, learning a bit of CMakeFile syntax, and doing CMake builds against the part of the KDE trunk you are trying to work on. The example that i worked with was a Plasma widget. Pulling down just the widgets, and via command line changing to the directory of the one i wanted to build, and running "cmake -DCMAKE_INSTALL_PREFIX=/usr". From then on using Code::Blocks as my IDE, and running "make && sudo make install && plasmoidviewer my_applet" to do all the dirty work. After an hour or so, i became rather efficient at switching between my terminal and my coding environment. This is still not even close to satisfactory. It may work, and Code::Blocks was fantastic for maintaining my sanity ( which fades with a significant amount of Mac development ), but other than that and the brilliance of the plasmoidviewer there was little convenience. 

Qt Software are busy working on an IDE/Designer called QtCreator, which does show some promise, but is more of a designer than a solid IDE. Playing around with it was somewhat satisfactory, but again it was not packed full of features one might expect on a full blown IDE. There are also many limitations, and it is purely geared toward Qt development ( and apparently KDE development, however i couldn't get this working ). This said, it does what it claims to very well, that is being a GUI designer with some coding features.

MonoDevelop is an interesting one. In playing around with it before, i have been very disappointed, however trying it again ( making an effort to get used to C#1 ), i am somewhat impressed. It still crashes pretty occasionally ( especially when it comes to things form/dialog related ), however, in a normal usage case, it feels good. It is very responsive and fast, which always pleases me ( it is far from the slugs that are Eclipse and Netbeans ). Code complete and parameter listing is as it should be. In my opinion, an IDE is worthless without decent code completion, suggestion and parameter listing. Looking in header files to see the method declaration is something that people shouldn't have to do, that is what the IDE is for. Code::Blocks is relatively good in this respect ( far outpacing some commercial IDE's like XCode ), but MonoDevelop is up there with Visual Studio, which i still think is the best IDE at the moment.

Free flowing code is what i strive for. Frustration caused by waiting unnecessarily for standard IDE features will drive a developer insane. The more streamlined the IDE, the more streamlined the development process. The more complicated the primary toolchain ( KDE style ), the further we are from getting new developers interested and the harder it is to make a good IDE that deals well with them. My suggestion of a way forward would be this:

It pains me to do this, but i think that MonoDevelop is the way forward. While Code::Blocks is fantastic, it is based on old technology ( wxWidgets ) and although has amazing support for different project templates, it does lack support for different languages. MonoDevelop has relatively poor C++ support at the moment, however it does have an amazing feature set and should be expanded as much as possible. At this point, a large percent of the "hardcore" Linux/OSS evangelists are about to open up the comment box and give me a lashing about how bad and evil Mono is, but at some point we need to accept that if we are to attract developers from a Windows environment, some Windows tools ( along with cross platform support ) might not be a bad idea. I think that pushing MonoDevelop development forward, adding solid C++ and Java support, and potentially long term support for Qt widgets would make development on Linux a dream.

Notes:

1Why C# you say? I am a relatively confident C++ developer, and love the speed of the language, however, there are some advantages to other languages. I would like to give Garbage Collection a chance. I know from the start that it will not be as quick, but there are many advantages to not having to worry about cleaning up. Many modern language features are very convenient ( i won't get into details, there are enough forum discussions about this ). It is Windows and Linux ( like Steve Ballmer, i have less interest in Apple ) compatible, one single executable two platforms. And to be honest, i see Microsoft as a lesser evil than Sun.