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.'"
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:/
Good thing the Christmas Island people have made it safe for the goatse:/ handler.
Trolling is a art,
I'm sorry, but to me that bit just reduced a potentially informative article to yet another trivial Slashvertisement.
"Ask not what your country can do for you." --John F. Kennedy
My favorite one of course is pr0n:/. But for some reason I get buffer a overflow error - anyone know why? Anyone get pr0n2:/ working yet?
After all, KDE isn't the only popular open GUI toolkit for Linux.
Not to be a nervous-nellie, but isn't adding more networking/protocols to the desktop just asking for more hacking problems?
Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
The one thing that I do not like about it, is how long it takes to boot. Windows (and probably mac, never really used it) have linux/kde beat for loading times. I really wish there was a distro that could integrate kde into the booting process rather then boot linux then kde - like back in the dos/win days...
spend money here
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.'
And the entire Windows OS is decked out with enough user friendliness for most people to use, and, as I put it, 'KDE has a long way to go to catchup with the userfriendliness of Mac OSX and Windows.
Windows, as much as everyone hates it, is still more user friendly than KDE. If they'd spend more time on user friendliness and less on robust (aka confusing, complex) features, they'd find more people willing to try it out.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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)
That didn't take long. I was thinking that I would have to scroll down more then one page to see that garbage.
KDE is pretty damned easy to use and consistent too, it's just that not all applications are written in QT, just as not all Gnome apps are written in GTK. So, you get some apps that don't fall in line with the look and feel of the rest of the OS.
So is the way of the Linux desktop right now, and you can't single out KDE for that.
- It's not the Macs I hate. It's Digg users. -
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
I thought this was pretty boring until I read this part:
Being able to do all of these things from a web browser is definitely a nice parlor trick, but in reality it's not a very easy way to use a computer. The real power of these protocol handlers is unleashed when they're used within various KDE applications. Any of these protocols can be used from the KDE file dialog, allowing files to be opened from or saved to any protocol!
I must say, as much as I don't really like KDE, that's really slick, and potentially very useful. Nice job guys.
(I'll even withold bashing and pro-gnome comments for the sake of sanity)
RTFA... This has nothing to do with which application to launch to deal with a specific file. You are thinking of file associations.
The KDE feature discussed here is a compatibility layer that allows users to treat a files located elsewhere as if it is on the local disk.
Instead of having to use sftp to download a file from a site, or wget to download a file from the webserver or even evolution to download a file from the mail server, you can just use one common interface for all files reguardless of their storage or access method.
This means a tighter and more consistent user experience.
SO there!
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?
I don't get why it is useful to be able to type devices:// or whatever. For some of these protocols the ramifications are totally unclear: if i'd type pop3://myserver/mymailbox would that actually download my messages and effectively erase them from the server? The useful protocols are covered in Win(XP) very well, including the most useful (not mentioned in the article) : webdav over https.
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?
...yet.
Microsoft won't see any need to add new features as long as it's users don't find out, and it's market share remains 90%-ish.
Once it DOES feel threatened though, it'll pour resources and add all the features to it's OS that it thinks will maintain it's dominance. (think Mac/Windows, Netscape/IE, Java/C#).
But it'll probably ultimately fail this time. I'm a Windows fan, but I'm realistic: Linux will win in the long run.
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 .
Like what kind of catching up? Like this?
KDE on Mac OS X
Non sequitur: Your facts are uncoordinated.
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.
Us computer geeks like this because we think of things as networks and protocols. However, the rest of the computer users don't. tar:/ is no more intuitive than double clicking on the .tar file and opening it.
Saying Windows and MacOS has to catch up implies that these are feature people want, or would want if given the option. I think treating compressed files like folders like they already do is more intuitive and makes more sense. I think they got a little carried away with this.
That's not really the same thing. KIO protocol handlers allow KDE apps to understand new types of filesystems. So you can define a module that allows any KDE app to transparently have access to a "gmail drive." Can you do that in Windows, without any changes to applications?
A deep unwavering belief is a sure sign you're missing something...
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...
Why does Microsoft need to catch up? Anyone can write an Asynchronous Pluggable Protocol (the handlers for different url monikers). I've written two of them for different applications I've written. It's a great way to tie browsers to HTML not stored on a web server.
mk-its: is used in the HTML help system, and ms-help: is used with the MSDN, and there are probably a few others that most people have never heard of.
But like I said, why is it up to MS? Anyone in the open source community could write APPs for Windows to add this kind of functionality if there were a demand for it, so I suspect there's little or no demand for it.
I've been through some KDE code myself (not Konqueror, though, but the code in question is in KIO, not konqueror), and the code quality is very good. It's not as good as Qt, which is pristine as the virgin snow, but pretty good nonetheless.
A deep unwavering belief is a sure sign you're missing something...
SSH+SCP would be really nice. fish:// on the other hand, is shear brilliance. It uses Perl on the server side to do some things that are not possible with just SSH+SCP. Those are great fallbacks, but fish:// is innovative. But, I'd be happy with just SSH+SCP. As far as I can tell, it doesn't exist in OSX.
This brings me to another annoyance with OSX: It doesn't tell you when it doesn't know about a protocol. I can tell my OS X 10.3 machine to connect to a server. For a URL I type in "bogusprotocol://foo@foo.foo". The Finder tells me, "Connection Failed. No response from the server. Please try again."
WTF? I'd prefer something like, "You moron, you've just typed in a protocol name that doesn't exist." Please don't say, "Sorry, but we couldn't connect to this perfectly valid URL because the host wasn't available."
-Peter
. Penguins Surely Ca
Then use Konqueror, and KMail.
The only way to get this across every single application is to include it at the filesystem level. First, the KDE developers aren't kernel hackers, so they probably don't have the expertise to write such an extension.
Second, even if they did, it would probably incite a giant debate in the Linux kernel mailing list when they presented it (like with Reiser4), and the net result would be that it wouldn't be in anyway. So it'd be a bunch of patches and you'd have to use a special kernel to use KDE, which would be awful.
The KDE developers aren't going to rewrite every single application out there to use their functionality (and if they did, people would complain because pine depends on KDE).
In other words, don't choose to use a hodgepodge of programs, and then complain that it works like a hodgepodge of programs.
I've come for the woman, and your head.
these are clients. This is like adding an ftp client, or a normal e-mail client, or a straight browser, or.... Basically, the only security risk is that more code was added. But that is common with adding an new functionality. The nice advantage of this is that a new app can get well tested code, and of course a common app can gain a new protocol.
I prefer the "u" in honour as it seems to be missing these days.
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.
Apple is doing this stuff (e.g. you can mount WebDAV servers), but Apple is doing it right by integrating network resources into the real VFS layer so that all applications can access them. KDE's I/O slaves are not real filesystems and are not accessible by all applications.
s e+ Gateway
Not necessarily.....
http://kde.ground.cz/tiki-index.php?page=KIO+Fu
But do they have the expertise to write a user-mode NFS server that uses the protocol in question as the back end? There'd still be some platform-dependent crap to do the NFS mount (probably using a port other than 2049, if the platform's NFS client supports that), and there might be some file systems where that doesn't work all that well, but it might work well for many of them.
Unfortunately, NFSv2 and v3 don't have "open" operations, so read/write file systems might be a little painful if the file system protocol is oriented towards copying entire files, as you'd probably want to implement writing by writing to a local copy of the file and writing the file back to the server when it's closed. NFSv4 might help, although that'd help only on OSes with NFSv4 clients mature enough for that purpose (Linux's might be; I think Solaris 10 will have a v4 client which might be; there are v4 clients under development for the BSDs, although I don't know whether they'll end up in OS X at some point).
For access to tarballs, zipballs, and the like, read/write access would be tricky, as you easily can't update individual files in place. If you offer read-only access, a user-mode NFS server would probably work.
"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.
Correct, although...
...that doesn't mean that suffixes aren't needed at all on UN*X - try calling a C source file "foo.f" and see how eager GCC, for example, is to compile it:
At the desktop GUI level, some UN*X desktops, such as KDE and, I think, Gnome (and possibly CDE and others) don't require suffixes in many cases, as they do file-style file type determination by looking at the file's contents, and give the file the right icon, launch the right application when you click the file, etc., but whether that behavior can be attributed to "Unix" is another matter. At least one UN*X desktop is mainly suffix-based and doesn't do that sort of "look at the file contents" file type determination, although I guess if the file's on a file system that supports resource forks and the resource fork has the right type and/or creator code it might work.
Umm, no, OS X definitely lets you add handlers for arbitrary URL schemes, and I infer from what others have said in replies to the original article that Windows does so as well. They don't have an IOSlave equivalent, but, at least in OS X, I'd be inclined to implement that as a user-mode NFS server, which means it'd be more general than an IOSlave, because it'd be usable by all applications, not just KDE applications (see, for example, OS X's mount_ftp, which I think might work through a user-mode FTP server with an FTP client as a back end). If possible, I'd be inclined to do it with a user-mode SMB server in Windows, although that might be less likely to work on port other than 139 or 445 (and thus less likely to run without interfering with any standard SMB server running on the machine).
...and ctrl-x probably works in a lot of them as well.
And, given that Qt switched in Qt 3 to the closest thing to a standard way of handling the PRIMARY and CLIPBOARD selections in X, and that a number of other toolkits, including GTK+, have always done that, it would probably work even between applications using different toolkits in most if not all cases.
I.e., bitching about copy-and-paste in X11 is getting a bit old, at least for complaints about it not working at all, even for text. Perhaps for non-text formats there needs to be a bit more work in the toolkits and applications, but, as I remember, the selections mechanism in the ICCCM does have a mechanism to register data types and to have a recipient of data find out the types in which data in a selection is available, so they can choose the "best" type (e.g., it might be available as rich text or plain text, so that a word processor would fetch the rich-text version but a terminal window would fetch the plain-text version).
It's garbage because it's off topic and very typical of a Mac zealot to say something like that.
I admit, you don't sound quite as unresonable as some Zealots, but you did post that just the same. The article nor slashdot post wasn't about usability, it was about resource transparency.
And to proclaim that KDE is "ugly and clunky compared to OS X or even windows" - such an objective thing say that you can't just preach it like it's fact. Personally, I feel too confined in OS X. It's okay I guess, and I like the shadows under the windows, but I find the interface to be unyeilding and stubborn. KDE is prettier then Windows I think, and it functions very similar to Windows. And I think the Windows UI is very usable, it works for me.
Just because your preference is MacOS doesn't mean that KDE or Gnome are worse.
My KDE desktop is clean, it's fast, and very accessable. I really don't see how I can ask for much more than that at this point? The rest is on the horizon, and with the rate that OSS progresses it won't be long before there's no more arguement against it.
- It's not the Macs I hate. It's Digg users. -
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.
Wow I like this one.
Here they are
most of "Connect to server" server connections don't work, example ftp:// one version asks for password, but latest OSX patch does not. Copying files doesn't work as it should.
Network interface was simple. Chooser and that was it. Now there is trashed all over the place. Network in finder supporting SMB only???
Start menu has gone bad since OSX.
Mail has fatal flaws. (Besides its fatal unusability)
You can't control with keys on dialogs or popdowns. (Buttons I mean)
Themes aren't consistant. And please don't say BrMetal is multimedia, standard is other software. Even Apple wasn't consistant with this feature
Window Titlebar. Was clear, now you get ughly and bad positioning.
Mouse (ok, that one was bad and still is)
OS9 detected new monitor. OSX doesn't. I wouldn't even notice that if I wouldn't disconnect 22" monitor and connect 17". Guess what (blank screen)
File layout was perfect, now it isn't.
System files were perfect. Throw preferences to trash and it works. Now it doesn't, Everything is displaced on various locations. (even Windows don't have such bad file layout)
You could reinstall system, copy (not install) software and preferences. You could work. Now it is not even a bit better than Windows.
Response was fast, now eye candy is slowing down everything.
Harddrives often get locked in OSX.
Printers don't support CMYK ICC profiles (OS9 was supporting them). Sory, buddy. cups is not CMYK proof concept. You can install rip though, but that is something you can install anywhere
Really bad system menu layout. It was almost perfect
No more delete and it is uninstalled. It was trashing all over the place
Everything is too big without system scaling option. (There wasn't scaling in OS9 but at least it was usable on smaller resolutions)
Should I continue????
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
As a web designer, I feel that Konqueror 3.3.1 is miles ahead of 3.2.* and Mozilla. I'm constantly surprised at how well it renders CSS.
testing out my trending skills