Sometimes it is difficult to find the location of opensource software. It is not always available where you would look for it. I have been looking for the source code location of Adept for a while now (well, I haven’t wanted it so badly that I was willing to install Ubuntu.) Currently the only source copies are in KDE svn. Get adept from anonomous KDE svn this way:
svn co svn://anonsvn.kde.org/trunk/playground/sysadmin/adept
Shared specifications and shared standards are an admirable goal as long as the “standards” are not acting as limitations to the advancement of a given technology. This was the problem that KDE ran into with the use of Corba. It was a open and shared standard used by KDE (and Gnome) in its early development. But we quickly discovered that it became a nightmare to manage/extend to the more advanced uses that we wanted to see KDE move towards. The decision was made (and lots of “shared standard” developers SCREAMED about the change) to switch to a custom KDE specification now known as KParts. History has shown that decision to use KParts was the correct one, as KDE would NOT have progressed to the level it has using Corba.
As long as the standard is good for KDE development and advances our ability to provide application solutions to users (and developers) then I am all for shared standards. But the moment those standards hold back KDE development in the interest of some “perceived” value from shared specifications. We can all agree on standards up until those standards have the net result of holding-back all of our development efforts equally.
Think of specifications as food for software. Good standards will help you (or your software project) grow strong and healthy. Bad standards will make your application bloated, lethargic, and will eventually be the cause of most of your application “sickness.” Standards are NOT more important than the applications (arguably they are part of the application, but a part is seldom more important than the whole.) Because they are NOT more important than the applications themselves, comments like this verge on being insulting.
The fact that KDE gets appreciated this much and that KDE is the market leader in UNIX and Linux desktops today is negligible compared to the extremely important effort to create a single specification of the free desktop environment.
Also, I think too many people get shared specifications confused with open specifications. KDE (and Gnome for that matter) will ALWAYS have open specifications because of the very nature of F/OSS. Open standards are very very important, shared standards are less important. One could argue that Microsoft DOC format is a shared standard because just about every office package in existence tries to write and save to it. That doesn’t make it an open standard.
I have not been in the mood to blog lately. I am not entirely sure why, but it may have something to do with just being burnt out. In spite of how I feel I must get these links up. That said, I have been scanning news feeds for articles about Linux authentication mechanisms. Linux (via PAM) has the uncanny ability to authenticate to everything from a Windows AD network to SSL shared keys. I am fairly sure it would even be possible to get PAM to use the current state of my toaster oven to validate a user. Of greatest interest to me is, getting Linux to use use LDAP for network authentication. As such we have todays links.
Hopefully I will be back to my full blogging glory after this weekend. Lots has been happening in the world, in my life, and in my home; but until I get out of this slump my body just keeps saying “NO blogging today!”
Martijn Klingens has extended is post on KExtProcess. The new article covers API documentation and compares KExtProcess to the old KProcess. The simplicity of design should make it an easy port. Hope it makes it into kdelibs by KDE 4.0.
kconfigure, my KDE build management tool, uses KProcess for its handling of automake, qmake, and checkinstall functionality. It does this because fundamentally these tools are command-line driven tools without a library interface for C++ to work with. The problem with KProcess is that, while it is probably the most powerful command-line processing library available, it is still very limited. Evidently I am not the only one with this problem as Martijn Klingens has released his updated KProcess-like tool KExtProcess.
The beauty of KExtProcess is that it not only handles command-line communication processing (i.e. STDIN, STDOUT, STDERR, etc..) but that it is network transparent. It also supports the concept of “profiles” that allow you to string together commands into a single “profile” that is loaded before the process is started. This allows things like: ssh’ing from one machine, to another, to a third before running a command locally on that third machine; or remotely accessing a machine as a one user, and then su’ing to root before beginning your process as root. While KExtProcess is still in its early stages, it will, no doubt, quickly achieve its place alongside KIO and DCOP as one of the powerful *nix desktop technologies in existence.
CVS Auto-updating is a blog post on how to get CVS to manage auto updating when working with a web server or a local repository. Nothing fancy, but it works. Here is another option (releated to KDE management) for auto updating:
umask 022;
$ENV{“CVS_RSH”} = “ssh”;
# read the message to make procmail happy
while()
{
chop;
$subj = $1 if(/^Subject: (.*)/i and !defined($subj));
}
exit 0 if (!defined($subj));
exit 0 if ($subj =~ /\/\.\.\//);
$subj = $1 if ($subj =~ /^\S+: (.*)$/); # remove branches
$subj = $1 if ($subj =~ /^(\S+).*$/);
# Choose here which subjects to filter upon. Another solution is to filter
# in .procmailrc of course
if ( $subj =~ m#www/areas/koffice# || $subj =~ m#www/media# )
{
my $home = $ENV{“HOME”};
my $cvsroot = “$home/koffice.org”;
open LOG, “>>$home/cvslog”;
my $date = `date`; chop($date);
my $path = “$subj”;
if ( $subj =~ m#www/media# ) {
$path = “$cvsroot”;
} else {
$path = $subj;
$path =~ s#www/areas/koffice##;
$path = “$cvsroot/$path”;
}
print LOG “$date: subj is $subj\n”;
print LOG “$date: testing path $path\n”;
#print LOG “$date: mod is $mod\n”;
$path = “$cvsroot” if (! -d $path);
if (-d $path) {
print LOG “$date: updating $path\n”;
$SIG{ALRM} = sub { $SIG{TERM} = sub{}; kill TERM, 0; exit 0; };
alarm 600;
my $out = `cd $path; svn up 2>&1`; ## use cvs up here instead of svn up if you use CVS
print LOG “$date: output–\n” . $out . “\n”;
}
close(LOG);
}
Thanks to David Faure for the script.
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.
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.