Category: KDE

There has been a heated debate going on in the Gnome world over which development environment to integrate on a native level with the desktop layer of Gnome; Java or Mono. The dark secret that every Gnome developer subconsciously understands in their rigid little pre-OOP based minds is that C is killing Gnome’s ability to compete effectively in the F/OSS desktop world. All the core Gnome developers understand this, as do most anyone who has had to develop on Gnome. To make C a truly useful language for desktop application development it needs a couple things; like encapsulation, inheritance, and polymorphism. If these qualities sound familiar its because they are quite literally the defining characteristics of object oriented programming. A cursory look at GTK shows many a half-assed attempt to implement said qualities in Gnome libraries even though their primary language of choice doesn’t support them natively. Suffice to say that Open Office, Mozilla, KDE, and almost all sane desktop software application are developed in C++ (or similar OOP languages) these days. Fundamentally Gnome HAS to make a switch; and this switch will decide the future of the Gnome Desktop.

Now this is where things get interesting. Redhat has decided to back Java (or more specifically Classpath and gcj, an open source Java implementation.) Why? No one is really sure but it should be noted that Havoc Pennington (head of Redhat Gnome development and probably the second most famous talking head in the Gnome pantheon) has gone so far as to say that Redhat will not and CANNOT include Mono in its version of Linux. Rehat is the single largest Gnome contributor, the largest corporate Linux distribution, and employees more Gnome developers than any other single employer. Not including Mono (and not supporting it) would be a huge blow to the success of Gnome on the Linux desktop. So how far is Redhat willing to go to keep Mono out of Gnome? Evidently they would be willing to actually FORK (yes you heard me right) Gnome.

Now, easily the most public face of Gnome development is Miguel de Icaza. Miguel is most famous for a little project he works on called Mono. Yes, that would be the same Mono that Redhat will not ship. And easily some of the most interesting technology to come out of Gnome in the past couple years has come from Miguel’s platform of choice (things like Beagle.) Mono is the obvious favorite for the future direction of Gnome. So much so, that Java doesn’t even register on the radar of most Gnome developers.

So here is the rundown. 1) Gnome needs to move from C if it ever want to bring modern applications to its desktop environment. 2) Mono is the logical direction for Gnome to head. 3) Gnome’s most influential developer is ONLY willing to go towards Mono. 4) Gnome’s most significant corporate contributor is not willing to use/ship/support Mono. 5) That same contributor is pushing Java. 6) Very few in the Gnome world actually want to use Java (minus Sun and Redhat) on the Gnome desktop. 7) Redhat is actually willing to fork Gnome (the thought of switching to a superior desktop never even crossed their minds) rather than use Mono. And finally, 8) Many of the Gnome core developers would rather stay with C than bother with the whole mess.

Man, does this sound like a desktop with a bright future! Oh, ya. By the way. Because of the flexability, and power of the Qt environment. You can already make native Java applications in KDE. And they are a whole lot easier than making them in GTK#, AWT, or Swing.

Got the heads-up for this from Michael Pyne. The newest version of Gnome, 2.10, will include among its many features; the editor will be able to highlight the current line, highlight matching braces, and single-click preference in the file manager will also affect the archive manager.

Seriously, at this blazing pace Gnome should catch up to Windows around 2075 (assuming Windows does nothing) and maybe it will catch up to KDE sometime around 2120 (assuming again, no action on KDE’s part.) How is it that such a desktop is even considered in the same league as something like OSX, Windows, or KDE?

BTW I am typing this in a web browser text field within KDE, with auto spell-checking. Wonder how long it will take them to implement this.

I know I have been on a KDE rant as of late, but I find that the technology continues to amaze me. For example, Gnome decided that (for compatibility sake with Windows GTK applications) that it should have the ability to reverse the button order on their dialog boxes. You see, a couple years ago Gnome made the decision to move from the button order to the MacOS style button order of . The enter button, because of this design, always defaults to cancel instead of ok. Well here is that patch to allow selection of the button order.

For good measure, KDE decided that, for compatibility with MacOS style interfaces it would allow its dialogs to select their button order. Here is KDE’s patch.

Seriously, thats it. Four lines! Four lines and all the KDE dialog button get re-ordered. All KDE applications inherit this change automatically. Here is the kicker, Gnomes patch is around 266 lines; and it will only affect two-thirds of their applications. That is why Gnome is getting its ass handed to it by KDE. Fewer developers, fewer lines of code, and more functionality.

I am collecting scripts for automating the process of getting, building, and installing a KDE desktop from cvs/svn. When I posted the question on #kde-devel, I got answers from the who’s who of KDE application development. Here are some that I have collected already.

• Aaron J. Seigo— is a core KDE developer and responsible for Kicker and the Tenor project. A god in the Linux/KDE world.
• Ali Akcaagac–Check out getkde.sh and kdemake.sh for excellent build examples. Actually, oGALAXYo (aka Ali) is a Gnome, Amiga, AND KDE developer. Who put this guy get on the list?
• Michael Pyne— Another KDE application developer. His script kdecvs-build is fairly well known among Linux desktop application developers.
• Waldo Bastian— May be responsible for more of KDE (as it is today) than any other developer. Currently also working on Freedesktop.org, but try not to hold that against him.
• Thiago Macieira— Another super powerful, blah blah blah, KDE god, blah blah blah… Does, well, everything in KDE.

That is something that never ceases to amaze me about free software. Some of these people are considered super-stars in the world of hackerdom, but they will stop to answer questions and pass along code (or for that matter just talk) with anyone who is interested. Its like the first time I had a Perl question and could not find an answer on the web, so I sent a message to a Perl mailing list. Larry Wall answered by question… the inventor of Perl.

This doesn’t happen in the rest of the normal world. When you need some help with your taxes, you don’t simply call up Allen Greenspan. Nobody messing around with their own comic book, sends letters to Stan Lee for advice. Even in the computer world this is unusual; do you really think Steve Jobs is gonna help you out with your Apple? Or that Bill Gates will tell you how to debug Windows XP? It just make working with free software that much more, fun.

Found another old link I wanted to archive, this one is to Chris Howells’ Site where he describes doing backtraces in KDE. Its very simple, development 101, stuff but its useful to non-KDE developers.

News Forge has a side by side comparison of KDevelop and Microsoft Visual Studio .Net. The article compares general application capabilities in the areas of UI, editing, compiling, frameworks, integration, and documentation. As would be expected by anyone familiar with the two, KDE/Qt thumps .Net in framework, UI, RAD design, and overall flexibility. The author also does a good job of noting some of the places Kdevelop is lacking. Here are some of my favorite quotes:

I found KDevelop is much better than I had expected before I started to actually work (as opposed to just play around) with it. KDevelop is more feature-rich than Microsoft’s product — and we’re talking actually useful things here — more flexible, and better integrated with different programming languages, frameworks, and third-party applications, and it has a less clunky user interface than the commercial contender.

And if Visual Studio existed as a native Linux application? I’d still rather use Kdevelop.

Qt, as far as its functionality, clarity and ease of use are concerned, can run circles around MFC without breaking a sweat, and similar can be said about GTK+. DotNet’s Windows Forms framework is a bit better than MFC, but still lags far behind Qt.

Overall, it was a very good review. The author brushes over autoconfig, probably the single hardest part of getting used to developing on Linux. If you are coming from a Windows world, the transition to autoconfig can be pretty difficult at first. The payoffs are distributed application building, multi-platform development (i.e. applications builds for hand-helds, desktops, and mainframes; all in the same source), and multi-application build logic.

If you have not had the opportunity to try Kdevelop and KDE/Qt I suggest you try out Knoppix a full featured KDE/Linux operating system on CD. Simply boot to the CD and run Linux. No install necessary. When you are done, you can remove the CD and boot back into your safe Windows environment. Knoppix will even access your Windows partitions, letting you save files to harddrive.

Was looking for a couple links on Friday and had to go searching for them. That is entirely unacceptable considering I have this nice blog to store all of my important links. So here they are:

• KDE components— An overview of the advantages of KParts technology and it functional use inside of KDE. It also shows some of the staggering advantages that KParts provided over Corba.
• No Corbra— An explanation of the limitations of Corba and vicariously the technological limitations Gnome (who chose to stay with Corba entirely too long.)
• KDE 2.0 Technology— An old but surprisingly relevant explanation of some of the core KDE technology. The decisions made by the KDE 2.0 group have done amazing things to the direction and power of KDE. History has shown us that their decisions were (with the exception of the core KDE sound system interface) correct. After 2.0, KDE became the most popular Free Desktop environment in existence and its core technologies have made it the most advanced development environment in desktop computer history.

C++ language tutorial is a quick tip type tutorial (try saying that five-times-fast.) It provided some useful information to me concerning namespaces in C++.

On the KDE front a HUGE amount of activity is going on in preparation for the move to Qt 4.0. Because of the underlying structural changes that will take place, many developers are taking this opportunity to re-evaluate and extend KDE. Some of the more interesting projects are Lyceum, a KDE documentation project centered around tutorials organized the way college classes are. Tenor a Contextual Link Engine. The best way to understand it is to read the article. Its pretty amazing stuff and absolutely blows away ANYTHING currently available in terms of desktop search functionality. You can read more on Tenor here. This kind of innovation really shows off the power, flexibility, and integration that is available to KDE. No desktop anywhere comes can compete with KDE on the technical level! KDE is also moving from CVS for version control to Subversion which will allow for better control of existing code along with more flexible control of our projects. There is even talk of porting KDE to Windows. Lots and lots of code theory with lots and lots of work to do. The future for KDE is looking very bright indeed.

Stephan Binner of KDE fame has assembled a collection of distributor patches. Distributor patches are changes that different distributions make of the KDE sources to change the default behavior of KDE in some way.

For example Redhat would (for most of the Redhat 9.0+ versions) disable some functionality that KDE has that Gnome did not have because of a desire to see Gnome do better. Not all patches are for malicious reasons though. Many of the patches seem to be fixes to get specific compile time options working. Lindows has a patch to add text to kicker, thereby making it more “Windows like.” Overall there are some interesting modifications to KDE.

Windows, How To Work Them is a tutorial chapter of the KDE Users Guide. The parts that are most interesting to me are the kstart application (for starting windows with specific window management facilities. kstart lets you start applications on specific virtual desktops, with/without specific window decorations, present/absent from the taskbar, etc.. Thus providing a dynamic scripting interface for detailed window management.

The second utility is ksystraycmd. Ksystraycmd lets you load ANY application as a system tray mini icon. The application will can be set to load in the background and minimise to the system tray just like the volume control or windows update. Want quick access to a calculator without having it on in your taskbar all the time, try:

The best part is that it works with ANY Linux application available, it doesn’t even have to be a KDE application.