KDevelop vs. MVS.net

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.

Corba and KDE links

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.

Linkage & Theory

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.

KDE in your own image

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.

KDE Scripting Tools

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:

ksystraycmd –title ‘kcalc’ kcalc

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

Real Applications without Real Programming

I have mentioned Kommander in previous posts. It occurs to me that it may be hard to conceptualize exactly how “functional” an application written entirely in Javascript, bash, or DCOP could be. So, anyone who is interested in some of the application capabilities of Kommander should check out Dik’s Kommander Applications. All of Dik’s applications, on that page, are written in Kommander without any real programming required. Another quick tutorial on using Kommander can be found at kde.me.uk.

Gtk vs. Qt

Linux developers have argued the benefits of any given language/toolkit sense the beginning of time.  One of the oldest debates is between Gnome/KDE.  As anyone who knows me (or reads this blog) can tell you I have a strong attraction to KDE because of its design strength and flexibility.  However I was not always a KDE fan.  I started as a Gnome user/developer when I first began on Linux.  At the time I thought Linux’s development tools (through my Gnome/Gtk experience) were pretty bad; but were getting better.

Then, one day, I discovered KDE/QT and have never regretted the decision.  I went from thinking that Linux development was harder/worse than Win32 development to realizing that Linux/KDE/QT development was better than ANYTHING else out there.  Think that C#/.NET is nice?  .NET is a giant leap forward in Win32 development, but still way behind QT/KDE development!  Any who, I found a couple articles that I read, back in “the day”, that helped me decided to give KDE/QT a try and I wanted to pass them along.

  • Toolkit Comparison — Compare Gtk to QT.  Its my experience that that 30% numbers specified are VERY conservative.
  • Why I Left Gtkmm — Comments concerning one of the “better” C++ toolkits for Gnome.
  • Gtkmm vs. Qt — Same author as above, more comments and responses to Gtkmm apologists.
  • Why Qt — Third article by said author.  Random thoughts about his project, Gnome, KDE, Gtk+, Qt, C, and C++.
  • More Qt — kuro5hin article on Qt.
  • Why Program for KDE — Dispels some of the more popular KDE myths.

KDE on the command Line, Part #1

One of the strengths of Linux is the ability of the operating system to work in either graphical user interface mode (aka GUI), like Windows 2000; or command line mode; like DOS.  The reason this is an advantage is that in many cases the addition of GUI components to the interface just add unneeded bulk.  Who needs a GUI on a web server?  The other advantage comes from extensive amount of fine grain flexibility that is possible with the command line.  Something that is simply not possible in a GUI.  For example the grep program (a text processing utility in Unix) has thousands of possible options.  Imagine trying to make a usable  GUI program with literally thousands of options.

One noticeable problem exists.  Historically working on the command line meant that you functionally lost the use of GUI tools when not in GUI mode.  For example, you want to read an entry in your GUI address book but only have command line access to your computer.  One would think you would be out of luck.  In addition, some applications gave you no way to control GUI programs from the command line

However, the superb design and tremendous flexibility of KDE has created an incredible bridge between these two worlds.  For example, want to use your KDE trash can while using the command line?  Try this:

kfmclient move <url> trash:/

kfmclient is a tool for opening and accessing file from the command line.  kfmclient automatically uses your KDE preferences to handle command translation.  Here is another example.  Say you want to open a file with your default KDE application handler (whatever that may be.)

kfmclient exec file:/home/weis/data/test.html

or specify your own program to open the file with (even non KDE programs)

kfmclient exec file:/home/weis/data/test.html mozilla

Why is this useful?  Because kfmclient understands KDE kio and dcop information you can specify anything that you would normally do in Konqueror.  This works particularly well for bash scripting.  Say you want to have a program that opens your remote computers /etc/groups file, over ssh, with THAT computer users default editor?  Here is a quick two line bash program for just such a case:

#!/bin/bash
kfmclient exec fish://192.168.1.25:/etc/groups

It will even open up the username/password dialog for you (don’t forget to check the “remember password” check box to have kwallet store the username and password.)  I gotta go for now, but this is just the tip of the iceberg.