By Brian Proffitt
Managing Editor
First off, I need to extend my apologies for the lack of an
Editor’s Note last week. I could offer up a myriad of reasons why,
but it really came down to not enough time and not enough to say.
It happens.
Not so this week; plenty of time, and plenty of things to say.
Let’s just hope it’s interesting.
While we were all watching the fall out of Red Hat’s
announcement and Novell’s CEO’s comments about focusing on the
enterprise desktop, meanwhile Canonical undermined their comments
with a very solid release of Ubuntu 8.04 LTS (Hardy Heron). I
pulled down the Kubuntu flavor of Heron yesterday, and thus far I
like what I have seen.
There will be other reviews, of course, more detailed than I
will provide here, and I invite readers to check them out. For my
meager part, everything seems to function well. I haven’t noticed
any great leaps in speed or interface changes, though I think the
font rendering is much better than I have seen in a while. One
bugaboo: my Gnumeric no longer has a minimize button (and the panel
menu’s Minimize command is disabled). Kind of weird, but
manageable, since I use Gnumeric pretty much the entire day to
storyboard the LT feed.
One of the things that gets me about upgrading to a new version
is the lack of dramatic changes. As I have written before,
everything these days is done in increments. There are no big leaps
anymore, particularly in the interface arena. Nor, I have come to
believe, should there be. One example: my wife was exposed to
Office 2007 at her work the other day and hated it; she could not
find anything she needed, having gotten very used to Office 2003.
She said she never had that much trouble when she started to use
OpenOffice.org at home.
Still, the geek part of me (everything from my ankles up)
sometimes longs for the heady days when new interfaces came out as
a matter of course. I remember being stunned moving from Windows
286 to Windows 3.0. Windows 95 and 98, I must admit, provided fun
times too–at least from the interface aspect. Mac OS X was like
ambrosia. GNOME 2.0 and KDE 3.0 gave me similar chills.
Today, though, interface designers are more conservative in
their changes, because while drastic changes may please the
geekatroids among us, they make casual users very nervous.
Lately, though, I have begun to get that little thrill down my
spine when I play with KDE 4. It’s an interface that’s pretty and
(bonus) so fundamentally different than what we have now, it brings
a lot of excitement to the table.
The typical fallacy about KDE 4 when people look at it is “oh
look, a pretty desktop” and form their opinions based on that. I
admit, I had the same thought. The Oxygen-themed icons and the
widgets are indeed very pleasing eye-candy. But under the hood,
there’s a huge set of differences that could fundamentally change
the way Linux developers code. To make sure I understand these
changes, I called up Aaron Seigo, the lead developer of Plasma and
asked for a basic rundown of what he and his team are doing.
To emphasize the impact of what the Plasma (and the KDE team in
general) are trying to accomplish, Seigo started with a bit of
history lesson.
In the beginning of the graphical user interface (GUI) universe,
there was PARC, and it was good.
Wait, too metaphorical, let me try again: in the 1960s and
1970s, when GUI research began, the limitations of the computing
environment (floppy-booted operating systems, highly rudimentary
networking, no multi-tasking to speak of) the file-based interface
concept made a lot of sense. It was a good metaphor and fit quite
well with the environment of the time.
Now, decades later, we have personal computers with massive
drives, USB devices, peripherals. So much data is floating around
that you simply cannot view or use all your files all at once. The
hardware has grown, but it’s left the GUI behind.
Seigo first got a hint of how things could be different when he
was watching graphic designers working at their machines. They
would tend to lump everything together into project-oriented
folders, where every file for a given project was placed into a
single folder. The designers would then open the folder, dump all
of the contents out to the desktop, and start working. Once
finished, they would move everything back into the folder, close
it, and start on the next folder.
This work process started him thinking: what would it look like
if you could manage everything–files and tools–for a given
project as objects? Instead of just managing files, you could
manage objects instead? These objects can be interconnected so that
whenever you accessed a file, a web page, or an application, all of
the related files and tools would open up, too?
A personal way of thinking about this for me would be my morning
routine. Instead of separately opening all of the files and apps I
use to put LT together, what if I could just visit the LT admin
page and have everything–Gnumeric, gedit, Pidgin, my Gmail
page–just pop open, identities automatically managed? That would
certainly be handy.
Anyone who uses multi-site book marks in Firefox can get an
inkling of what I am talking about. I can open up my browser now
and click a link to open the 16 pages I start looking for news for
LT. Now extend that to the entire desktop and you can get a sense
of what Plasma is about. It’s an object-based way of looking at the
information inside these PCs sitting in front of us.
Basically how this works is through the use of scripting
languages (any one you want) that build apps that run on the
interface, not the operating system underneath. These aren’t big
monolithic applications either. The scripting means that you can
exchange tools or whole sets of tools within the Plasma interface.
If you like a certain media player’s controls inside of your
Konqueror application, it will now be easy to just pull the
controls in with just a few lines of code.
Writing to the interface and not the OS leads to another
advantage of KDE 4: apps written to it now no longer care what OS
you are using. I watched the KDE 4 launch event
video on YouTube this morning and saw a Mac developer and a
Windows developer run the same apps on top of KDE 4/Mac and KDE
4/Windows. The apps (Marble, Kstar, Konqueror) ran just like their
Linux counterparts–and not a single line of code was changed in
any of these applications to port them. They were running on
Plasma, and were quite happy to do so.
I have
touched on this capability before, and have hinted that such
functionality could lead to a universal shell that ran on the major
operating systems and would allow seamless transitions for users
from one OS to another. Being the Linux advocate, I also hinted
that this could be the “gateway” for Windows users to Linux. A lot
of readers came back with “why would anyone average user use Plasma
on Windows in the first place? And what would be the incentive for
Redmond to install it?”
Fair enough. But even without such a future outcome, the
platform independence would still be huge advantage: non-PC
platforms (tablets, media centers, PDAs, phones) would now be far
more accessible for application developers. You could write your
app for Plasma and see it run anywhere Plasma fits. Without
porting. Instantly. In fact, in this year’s Summer of Code at
Google, there’s a Plasma project to stabilize Plasma further on the
mobile platform.
Closer to home, there’s always been the age old problem of app
developers wringing their hands about which distribution to code
for. “Red Hat? SUSE? Ubuntu? Mandriva? So many choices,” they
think, “guess we should just skip it.” And often they do just that
(completely missing whole point of the Linux Standard Base). When
KDE 4 is in place and Plasma is more stable (likely by KDE 4.1),
then such problems would be moot. Don’t know what distro to code
to? Then code to Plasma, and it won’t matter.
The possibilities, it seems, are far-reaching and quite
mind-stretching. It’s a free software project that promises to do
the one thing that no other software has been able to do to date:
bring us any information anywhere and anytime.
And, hey, it’s pretty too.