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.

Comux 001001

Mark Shuttleworth draws Karmic Koala.

Opera, all prettied up with nowhere to go

Anyone who has read a few of my posts, or even looked at my blog page will know that i am an Opera user. In general i find Opera to be a far superior browsing experience to any other browser at the moment, however, its failures are a reflection of the current market in which it is fighting. It has been a while since i have made significant comment on Opera, or the state of the web, and so i felt it was about time to throw something out there. In a way, this is an open letter to Opera Software, and a comment on the "browser wars".

While people in the open source world have been talking about browser competition for many years, it has only really been affecting the main stream for the last two or three. And while this may have been sparked by the superiority of Firefox over IE 6 in the eyes of many, what has really made the main stream realise the existence of competition is the aggressive way in which Google are trying to push Chrome. So much so, that the market share of Chrome has over shadowed that of Opera. And while Opera may be pleased that the marketing power of Google is helping enlighten many consumers, their desktop growth is not performing as well as it could. They mostly dominate the mobile market, and Opera link has encouraged many users to switch to Opera desktop, but there is still a big chunk of users that seem resistant to desktop browser change. Why? What does Chrome have that has given it 1% market share under 12 months, and Firefox almost an extra 4% in the same period?

Some strong OSS activists might attribute it to the fact that both Firefox and Chrome are open source or at least have underlying open source projects. And while i believe that to be a part of it, there is a lot more there. Both Chrome and Firefox are fast, but the average end user doesn't notice the difference. I feel that Chrome has gained market share through aggressive marketing and a technical user base jumping from Firefox to Chrome ( due to speed and the fact that tabs run in separate process threads ). And, in my opinion, Firefox is still gaining market share due to every security vulnerability found in IE. Yes, my implication is that Firefox is become the Corporate desktop browser of choice. It's a dream to manage on the network ( due to the built in updater ) and it is more secure than IE, so IT managers are more likely to recommend it. This is my general feeling on the browser market at the moment, so where does Opera factor in, and how can they take their rightful place?

Opera has a very odd relationship with the tech community. In this part of the browser conscious market ( maybe 30% of the total market? ), you get the Opera lovers and the people who prefer Firefox. While i fall into the Opera lovers, most of my friends and colleagues fall into the latter category. And being the confrontational, querying mind that i hope i am, i have dug deep ( sometimes into dangerous territory ) about why the aforementioned latter group prefer Firefox. This is what i generally got back:

"Last time i used it, it wasn't very good" or "i've never tried it" - the problem with the "Last time" is that it normally refers to pre-firefox, and although Opera was still great back then, now it is really the most forward thinking of all the browsers. Most of these users, have been impressed with what i have shown them of modern Opera, many have even changed browser. This is a market share that Opera could get if marketing was directed toward this group, but sadly, they are a minority, and marketing engines are always directed at the mainstream.

"It's not Open Source" - this group is also a minority, and while they strike up a point, Opera is not convinced it's a valid one. And i can understand why Opera would want to protect their source code, even if i would prefer them to be open source. Opera are an interesting company in this way. While they feel the need to push open standards and build a strong community, the still feel the need to protect their source, even if it isn't the community they fear. They have the makings of an amazing open source company, without the open source. Maybe there is a compromise to come? Well, at least i have a suggestion which relates to the next group:

"Plugin <x> <y> and <z> are amazing and i can't live without them" - fair enough. I can accept the killer app arguement because i live it everyday. Being a Linux user at home and at work switching between Windows and Mac, i feel the pain related to killer apps. My ideal platform would be a Linux system with KDE Desktop, Visual Studio 2008, XNA Game Studio, and XCode's analytical tools. Every time auto complete with C++ fails in XCode reminds me of the frustration faced by missing apps that you have become used to. So being able to understand the pain, suffering and depravity caused by not having your plugins, leads me to this.

Firefox is an open source project under a permissive triple license ( MPL, GPL 2, LGPL 2.1 ), so why not port their plugin architecture, or at least write a compatible plugin architecture. This way there is an available plugin API and the amount of people able and willing to try Opera could potentially double. Yes i can accept that it is a monster of a project to do this, but it is the kind of thing that can be done. This part could even be a community project by providing the community with the function callbacks and class structure available to Opera desktop. And no, Opera widgets are not currently a replacement. They are glorified, separate window web apps. Compatible plugin architectures are a progressive way forward, as can be seen by the amount of abstraction layers in a modern Linux system. Why not? Well, i can suggest a few reasons that i wouldn't want a plugin architecture like that of Firefox ( for example, plugins with that much power can mask malicious software ), but i feel that the advantages in terms of attracting a considerably larger user base would be huge.

Comux 001000

Just a wild shot at what these guys retail stores may look like... as much as bottom right looks cool, i honestly have no clue how it works and there is something slightly... religious looking about it.

Comux 000111

Leaking Plasma Everywhere!

KDE 4.2 is out and a lot of people are calling it the the KDE 4 release that is desktop ready. Honestly, i've been using "UNSTABLE" branch for a while, and there is a definite improvement between KDE 4.1 and 4.2. Plasma has been a somewhat controversial part of KDE 4, however given time, most people agree that it is the way forward. The technology and ideas in behind Plasma are very progressive and have resulted in the most extensibly beautiful desktop currently available on any form of hardware capable of running KDE 4 ( this sentence took a long time to work out, purely because saying "on the pc" excludes the large variety of platforms that modern desktop Linux supports ). So, having a new pc that can handle some decent Inkscape and Gimp work, i thought i should have a shot at some Plasma theming.

It seems that Plasma theming is actually really well documented, which one might not expect. There is an official 7 step guide to doing it which i partially followed. During the process of making a theme one would probably find this reference of widget component names extremely useful, i know that i found myself refering to it on several occasions. After getting used to many quirks and naming conventions, i ended up with this panel:

There is still more to be done, but this is my first attempt at theming Plasma, and i expect there to be many more in the future. I have been extremely thorough with what has been changed on this theme, and the panel is designed for each edge of the screen and non maximized versions ( from KDE 4.2 onwards there are theming differences ). All of the theme work is done in inkscape and i have dispose of a lot of the raster graphics which have clearly been imported from something like Gimp into the default Plasma theme. The theme currently resides here, but i am hoping to work out how to get it into the Hot New Stuff section within the theme selection dialog.

The desktop background in the theme screenshots can be found here, and is a great collection of Linux-tan desktops.

[Edit: Thanks to Jos Poortvliet for adding the comment, and yes it seems that when posting on kde-look.org, it automatically goes into the Get Hot New Stuff section. Last night i downloaded it onto my wife's KDE 4.2 Beta 1 desktop and it worked brilliantly]

Comux000110

if you do decide to search for lederhosen or frau antje, i am not responsible for what you see if safe search is off.

KDE Development, and the white elephant.

I've had my rant about whether Linux development is user friendly or not, and once again find myself fighting with KDE source. Everytime i have tried to make a simple app i spend more time trying to set up the environment than it would take to make the app. Maybe patience is required, but honestly, i hate admin tasks, and spending hours trying to compile stuff because paths are wrong and there is no quick ( <>

A virtualbox/qemu image with the KDE source and a build scripts and svn repository set up.

That would probably be a good place to begin. After that maybe we can work on having a nice graphical coding environment so i don't have to compensate for the lack of mouse with some ridiculous keyboard macros.