Hooray for Bluecurve
Immediately after its release and apart from the usual rough edges of every .0 version, Red Hat 8.0 generated a lot of heat. Much of it came from the Bluecurve desktop and from the changes RH made to standard KDE (for those who care, a good, though partial, summary of what Red Hat actually did is available here).
Red Hat had good reasons to create such an interface, apart from the unavoidable implementation errors. Even before the release, however, KDE developer Bernhard “Bero” Rosenkraenzer left Red Hat, claiming that KDE, as shipped in that distribution, is crippled. Since it's release, many GNOME and KDE fans are screaming because of this unrecognizable, offending, hybrid GUI. An excerpt from this posting sums up their feelings pretty well:
What you see is neither Gnome nor KDE in RH 8! Kind of comical actually.... I think...Redhat did [us] all a huge disservice with RH 8.
Personally, I am happy Red Hat melted the two environments together. If nothing else, this could be an excellent opportunity to realize that decently functional, good-looking desktop interfaces can be built on the assumption that KDE and GNOME themselves aren't really necessary and important in the first place.
In the rest of this article, I'll refer to them simply as K/G.
Back in 1996 and 1997, as a free desktop user I missed a few basic things—I'm still missing them today.
Making the cut-and-paste option always work between windows.
System-wide Unicode, instead of n different solutions for the Euro symbol.
One standard, centralized, font management system, for both display and printing.
A method for easy definition of the same hot keys across different applications.
Documentation written for end users, not people debugging a program.
Of course, K/G have slowly added come of these options. But I can't help but ask myself if these changes happened by mistake, while they were doing something sillier and (at least initially) throwing performances out the window (pun intended).
I would have liked to see, and here comes the real issue, programmers working to provide a path along which all existing applications could independently evolve in such a way that programmers could work less and end users could choose any combination of programs that maintain performance, integration and the userspace features listed above.
Instead, what K/G have said and done [during their development] sounds an awful lot like “let's throw existing applications away, even when they are perfectly good, and make everybody start using our programs”. One world, one Net, one (set of) windows—it's déjà vu.
I agree that without K/G Linux screenshots look like a mix of many different things—things that don't really want to stay close to each other. This point is made in this message and expanded in the related thread.
Beginners may indeed have an easier time if, for instance, the File Open dialog and other components were always the same in any application. In spite of this, however, I keep thinking that the whole “one look and feel” mantra is seriously overrated. I further believe that advancing toward desktop integration starting from the windows is the wrong way to go.
First of all, free software is successful because it started doing the “best of breed” thing decades before consultants created the slogan so they could overprice enterprise-level, process-oriented, Dilbert-R-Us, business “solutions”. Now some KDE-centric distributions are proposing that Mozilla be the standard default browser. Good, keep going: I might not personally agree, but I like open, pragmatic minds.
KOffice is trying to become a free FrameMaker with fully integrated spreadsheet and presentation capabilities. Being the ultimate solution to my idea of desktop/WYSIWIG publishing is why I'd use it, side by side with mutt and The GIMP—not because it browses local folders looking just like Konqueror.
What about developing effort? Mike Harris recently pointed out the huge amount of energy Red Hat is still forced to spend to make OpenOffice, K/G, Mozilla, X and fonts coexist, and I can't see why other distributions should be different in these respects. Speaking of fonts in general, Mike helps us understand why complaining about Bluecurve themes, in and by itself, is pointless:
The GNOME and KDE releases in Red Hat Linux 8.0, both are using Keith Packard's Xft2 and fontconfig, both of which are a core part of XFree86 now, and will be _the_ way fonts are done from now on period, in _all_ Linux distributions that are using X at all.
Keith has done a fantastic job at creating this technology, and we are very glad to be using it in Red Hat Linux 8.0, and to take X11 out of the 1980's finally.
For years I have made it a point not to lose sleep over any K/G, and now Bluecurve, crusade, on the assumption that the only meaningful road to really useful and flexible desktop integration is what I call a “path” above. A few weeks ago, I found the same concept in a message by Havoc Pennington. As he clearly expressed the idea in software engineering terms, and because it makes me really happy to see real gurus agree with the actual needs of the poor users, I'll quote Havoc directly:
Interactions between applications and the runtime environment really need to take place via documented, toolkit-independent protocols and file formats.... Documented, long-term-supportable protocols are the way to go from an engineering standpoint, vs. more ad hoc and implementation-dependent solutions.
The last and more important reason to stop bothering with K/G, Bluecurve and what-not is what I call the “migration mistake”. Please let's end this desktop environment tantrum and realize how futile it is to think Windows users will be freed from slavery by somebody saying, “Here, take this, it looks and feels just like Windows.” This last point has been thrown around too much, in too many places.
The question “How do I replace Microsoft Access” appears on the mail OpenOffice.org list every other week. Every time it reappears a bunch of solutions, usually MySQL-based, are kindly suggested. Almost always, though, nobody—starting from the original poster—understands what is really being asked. They're not looking for a “a stable, powerful and license-free DBMS which also has more or less the same buttons as Access” as much as they are looking for “whatever, even text-based, as long as it reads perfectly ten years worth of customer orders”.
Windows users (especially corporate ones) don't stick with Windows because they can't stand different interfaces, but because they have a really hard time converting terabytes of documents in proprietary formats. This is the real problem.
With respect to those Microsoft users not chained by data compatibility but only by mouse and start panel addiction, give them (and yourselves) a break. They couldn't care less about K/G. They want to see windows, any windows, so they can point-and-click all the way through. Everything that helps them to leave closed platforms and formats is fine. After the first thirty minutes, they won't even notice if their fingers are single- or double-clicking. Why should you?
Marco Fioretti is a hardware systems engineer interested in free software both as an EDA platform and (as the current leader of the RULE project) as an efficient desktop. Marco lives with his family in Rome, Italy.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
|PasswordPing Ltd.'s Exposed Password and Credentials API Service||Apr 28, 2017|
|Graph Any Data with Cacti!||Apr 27, 2017|
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
- Graph Any Data with Cacti!
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- IGEL Universal Desktop Converter
- A Switch for Your RPi