Slashdot Mirror
KDE: Breaking the Network Barrier
comforteagle writes "In this month's KDE: From the Source, entitled Breaking the Network Barrier George Staikos takes us on a walk-through of KDE's desktop networking protocol handlers in the vein of sftp:// webdav:// and a few really nifty ones I wasn't aware of like info:/ perldoc:/ and tar:/. The entire KDE desktop environment is decked out like this, and as George puts it, 'Microsoft Windows and Mac OS X have a long way to go to catch up with the robust, transparent functionality that KDE has provided since version 2.0.'"
This is one of the things that has impressed me most about KDE. The protocol handlers can make working with some of these protocols a piece of cake.
Also worth noting however, is the DCOP system integrated into KDE. The protocol handlers and DCOP can and do make a powerful combination.
"I filter at +6, and have yet to miss out on an important comment." (#822545)
I'm a regular MacOS X user. And I love MacOS X, but there are some things that I miss about KDE. I try to follow KDE's progress even though it is not my desktop of choice these days.
The network transparency of KDE is brilliant. I'm not sure where the holdup for OSX is, but I would kill to be able to open a location with cmd-k, fish://user@myhost
I suspect that for Apple to add these bits would require some OS level work as well as some finder work. I hope they'd take that opportunity to update the finder to be a cocoa application. (As a side note, the Finder continues to bother me. My Mac savvy friends and I joke that the Finder, Mail.app, and Quicktime teams are Microsoft moles trying to take Apple down from the inside).
Anyone have any speculation as to why Apple hasn't already done some of the truly nifty network protocols? They've already got a finder view for FTP (which, unfortunately is dog-slow). Still, Apple has proven itself as a very agile software company. They've got a track record for adding features correctly and quickly, but the lack of an SSH handler is baffling to me.
-Peter
. Penguins Surely Ca
Last time I checked, you could have any application take control of any protocol handler in OS X, even ones you've made up yourself, by simply adding a child to an array in an XML file located in the app's package. This actually caused the problem where a virus could auto-download a file to the user's hard drive and run the program via a url accessing that protocol to launch the app without the user's knowledge. Apple fixed this by making a dialog coming up the first time a file or URL accesses and app but I still think it was a dumb idea to link the internet and local applications in such an insecure way.
How about a box with the url, the app being called, "Allow" and "Deny" buttons and a checkbox to make the setting stick? Even then it's a bad idea. All it takes is one dumb app to compromise your system at user level. Launching these apps with guest permissions? Does KDE do these things? Why brag about such a dumb feature?
This is vaguely reminiscient of the old Unix maxim, "Everything is either a file or a process," except that now KDE calls everything an URL.
/dev/extensions/audiocd/track1, /dev/extensions/sftp/, /dev/extensions/webdav, and so on? This type of a trick would have allowed these extensions to be used in any app that recognizes the file system, not only KDE type apps.
Correct me if I'm wrong, but wouldn't the old way of doing this be something like
What was the reason for not implementing these as devices?
can one "cat perldoc://someuri/perldoc1" ?
if not then it is at the wrong layer to be "transparent"
plan's approach of a unified file system approach is far more transparent
a daemon runs and serves the appropriate files in the namespace as regular filenames
cat
grep bunny
etc.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Is the age-old question of 'does it belong in the kernel'. OSX's webdav and FTP client support accessable from the finder, the analogues to KDE's FTP and webdav protocol plugins, are in reality implemented in the kernel as a filesystem implementation, making them useable from *every*single* application running on the box, not just the ones linked into a particular application framework (KDE). The OSX implementations are truly remote filesystems, upon which I can 'cd', and 'vi' myself into oblivion.
But the downside is that these 'fancy' network filesystems are comparatively sparse relative to KDEs. And we're still waiting for, oh, say, webdav over SSL support (making it actually worthwhile for an intranet filesystem solution).
IF OSX could have retainted the 'filesystem drivers as userspace processes' mantra of the microkernel design philosophy, then we could have the best of both worlds. Especially if we could retain, say, HPFS, FFS, etc. as kernel resident drivers for efficency .
Reading comprehension ain't your strong-suit, is it? With regards to network-transparency, Windows and Mac *does* have a long way to go. Window's FTP functionality barely works. Meanwhile, I regularly use KDE's network transparency to work with my university account over SSH. I can just save directly to a virtual SSH drive, instead of saving on disk, then transferring, or e-mailing it to myself or whatever.
A deep unwavering belief is a sure sign you're missing something...
Geez... thirteen comments in and nothing positive to say about what the guy had to say. The fact of the matter is that on built in network transparency, KDE has no equal.
You don't really appreciate it until you use it and then forced to work without it. I present a real world example: a colleague wants some help with the IE CSS scrollbar colors. I open up KWrite, the "simple" text editor, select "Open" from the "File" and plug in the FTP url, with embedded password and all, into the open file dialog. A half a second later I was browsing their directory structure point-and-click in the open file dialog. I find the ".css" file and open it in the editor. I then make my simple changes and hit CTRL-S. The file was saved and uploaded back onto the web server in one simple keystroke combo. And that was it. Mind you all of this was done in KDE's most trivial of text editors and this feature is part of the desktop architecture meaning all KDE apps can employ this feature.
Try doing something like that with the default install of Windows/MacOSX/Be/whathaveyou. And that was the simplest of examples of the network transparency within KDE.
And that's just the network transparency aspect of it. The KIO architecture allows for some really amazing features on the local side as well. If you don't already know about the audiocd:/ slave then look it up or even use it. It will blow your mind.
Don't just take my word for it. Try it before you bash it. Please.
Some people would call such functionality within the desktop 'bloat'. I think before anybody says that, they first need to get themselves into the modern age. As the article mentioned, I find the fish:// handler to be one of the most oft-used handlers. Sure, I could scp remote files to the local machine, but it saves a lot of time to simply use fish:// in the file dialogs and such.
And it works *great* in Amarok, my audio player of choice. I no longer have to keep porting around my mp3 collection: I simply fish to my server and play them from there -- from anywhere. The only downfall, is that I need to force it to go to the next track after it gets to the end of a track, instead of automatically doing so, but it's a minor compared to the above ease-of-use.
They've forced me to dump dual boot at work, but back when I was dual booting Win2K and FreeBSD/KDE, the latter was objectively faster even though the former seemed to be quicker to the casual user. But when I did an objective test from bootup to displaying a webpage in the default browser, FreeBSD/KDE had Win2K beat by about five seconds (45 to 50 seconds totals). Win2K seemed to boot quicker, but it really didn't. When it looked like it was up and running it was still loading in the background. You would click on IE and end up with five to ten seconds of an hourglass cursor.
...and probably mac, never really used it...
I'm sure WinXP has improved in speed, and I'm sure you can find some lameass slow Linux distros, but the myth that Windows is faster simply is not true.
Then why don't you go find out first before making claims! From my ACTUAL USE of the Mac, it seems to me that the Mac is marginally slower to start up, even though the UI seems to be snappier.
Don't blame me, I didn't vote for either of them!
No, but being about to type sftp:// into a browser does make KDE more network-transparent than OS X, which was the point of the article! God, I like OS X myself (like Classic even more), but the special moron task force of the Mac user community is really out in force today!
A deep unwavering belief is a sure sign you're missing something...
Of course not everyone agrees that the Mac Classic HIG is desirable (*). While they may make the system easier to figure out for someone who has never seen it before, I stopped using Gnome about halfway through the push to implement the new HIG as I found each new release made it more difficult for me to accomplish the tasks I was trying to accomplish. Somebody needs to figure out how to make a system that is easy to learn without getting in the way of people who know what they are doing. Mac OS X sounds like it may have succeeded at this, I can't say as I have not had the chance to use it much yet, but Mac Classic and Gnome most certainly have not.
(*) at least not as implemented- i don't know the guidelines, I have only used systems that have claimed to implement them.
If I don't put anything here, will anyone recognize me anymore?
Better than Windows? Sure.
1) Visual consistency. Within KDE, I only use KDE apps, and in GNOME, I only use GNOME apps. As a result, all my apps look the same. They theme the same, use the same color scheme, etc. This is not true in Windows. The major Microsoft apps use different toolkits, so Visual Studio.NET doesn't look like Internet Explorer, and neither look like Office XP.
2) UI simplicity. In GNOME, the UI is very simple and streamlined. This is a direct result of the MacOS-influenced GNOME HIG. For example, Epiphany has 8 toolbar buttons and 5 entries on it's main context menu. Internet Explorer has well over a dozen toolbar buttons, and something like 18 entries in it's main context menu. Large toolbars and context menus are examples of bad UI design, because they prevent users from relying on muscle memory to access elements --- they have to do linear scans through the entries.
3) Consistency of menus. GNOME and KDE apps have very consistent menus. GNOME apps (mostly) put preferences under "edit->preferences" while KDE apps put preferences under "settings." In Windows, the major Microsoft apps differ quit significantly. In Visual Studio, in particular, configuration is spread out over several dialogs in different places.
A deep unwavering belief is a sure sign you're missing something...
Maybe I don't understand this 100%, but this seems to me a massive potential security hazard.
It's not difficult for me to imagine a web page link manipulating one of those weird protocol handlers in a way that lets remote code exploit it in the same way that several crackers have with a few of MSWindows' extra protocol handlers...
Thanks for the civil reply. I have used Windows quite a lot, and many different versions. Over the years it didn't get easier, but more frustrating. When I tried Linux/KDE, it felt liberating. Now, it might be my personal preference, but that's the way it is with me. Windows forces you to do things one way, which is not efficient, or optimal, and can usually not be changed or adapted. KDE, on the other hand, lets you change almost anything you wish (including the single/double click behaviour you mentioned -- directly from the KDE wizard you get the first time you run it).
For a long time, I had issues with some KDE behaviour, but with time, those problems went away. Windows, on the other hand, still has the same quirks and they are as annoying as ever.
"For every one geeky thing that OS X can learn from KDE, there are fifty things that KDE can learn about design, usability, polish, and consistency from OS X."
Don't start going about MacOS-X usability until you really look into it a lot deeper. They went all out for high 'walk-up-and-use' value, but not so much for actual usability. Many of the OS-X choices detracted significantly from usability that was present in earlier versions, giving apparent usability rather than actual usability.
This isn't to say their choice was wrong, but they were targetting new users and home users, not pro users. In very many ways, KDE is far more usable than OS-X, it mostly just depends on how talented the user is and what they are trying to do.
Apple has the privilege of only having one VFS layer. There is no such single layer that KDE could rely upon, since it runs on quite a few distinct operating systems.
In my mind there are two ways to look at it. You've presented one way: KDE must have this feature, and if the OSes won't provide it, then KDE must provide it in some suboptimal way.
The alternate approach is to say that mounting a fish or whatever is a feature that belongs in the OS, and if a particular OS supports it, then KDE will get that for free. If an OS doesn't support it, then KDE won't have that feature when running on that OS.