Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
KDE GUI

KDE: Breaking the Network Barrier 475

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 discussion has been archived. No new comments can be posted.

KDE: Breaking the Network Barrier

Comments Filter:
  • by grub ( 11606 ) <slashdot@grub.net> on Friday October 29, 2004 @03:09PM (#10666874) Homepage Journal

    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.
  • Marketspeak (Score:3, Insightful)

    by goldspider ( 445116 ) on Friday October 29, 2004 @03:09PM (#10666876) Homepage
    "...robust, transparent functionality..."

    I'm sorry, but to me that bit just reduced a potentially informative article to yet another trivial Slashvertisement.

    • Re:Marketspeak (Score:5, Insightful)

      by PitaBred ( 632671 ) <slashdot@pitCOWa ... minus herbivore> on Friday October 29, 2004 @03:12PM (#10666908) Homepage
      Says the person with the situational ethics sig.
      Perhaps you should just read the article and not pay attention to the slashblurb? Whether it's Slashvertising or not, it's still interesting.
      • Re:Marketspeak (Score:3, Insightful)

        by prell ( 584580 )
        The paradigm of "browsing" the web, ftp, mail, nntp, and webdav all from one application doesn't appeal to me. That is, I doubt I would use it. I can't see myself opening up another instance of what I was just using as a web browser, and then typing out an nntp address: they're totally different streams of thought, and I think that a change of interface (and application) is actually an important step the mind likes to take, since it is, after all, focused on a new imperative. Isn't that partially how we
        • Re:Marketspeak (Score:5, Informative)

          by cozziewozzie ( 344246 ) on Friday October 29, 2004 @04:04PM (#10667481)
          Sure, using all these things from the browser interface is stupid, but you're missing the point. Konqueror is not a browser, it's merely a shell which is very nice for viewing webpages. You are not supposed to browse most of these things (nntp, mail etc.) from Konqueror, but you CAN simply because you can embed just about anything into Konqueror.

          The useful thing is for example:

          - Writing a webpage in Quanta and uploading it directly to your webserver simply by typing ftp://blahblah in the file save dialog.
          - Streaming your movios from an smb share directly to Kaffeine without needing to use smbmount or anything similar. Or stream directly from http or ftp or ssh servers
          - Opening an mp3 song from an audio CD. You simply type audiocd:// in the file open dialog and you'll be able to find a virtual mp3 on there. You open it from amaroK and you get an mp3 encoded on the fly. OK, not the most useful usage and not sure if it works, but you get the drift

          The point is, if it works from Konqueror, it works from EVERYWHERE in KDE. Automatically.
  • Kwel (Score:5, Funny)

    by Anonymous Coward on Friday October 29, 2004 @03:09PM (#10666881)
    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?
  • GNOME compatibility? (Score:2, Informative)

    by Anonymous Coward
    After all, KDE isn't the only popular open GUI toolkit for Linux.
  • Errr.... security? (Score:3, Insightful)

    by Not_Wiggins ( 686627 ) on Friday October 29, 2004 @03:13PM (#10666926) Journal
    Not to be a nervous-nellie, but isn't adding more networking/protocols to the desktop just asking for more hacking problems?
    • by Chundra ( 189402 ) on Friday October 29, 2004 @03:21PM (#10667023)
      Maybe I don't know exactly what you mean, but all these protocols are already supported by various other clients. How is integrating it into the desktop asking for more hacking problems?
      • by gmuslera ( 3436 )
        Think in a web page with a javascript that launch any of the "dangerous" links there (i.e. scp if takes your certificates or even audiocd:), and maybe even interact with the new opened window thru javascript too.

        Ok, could be added security to avoid some of this tricks, but now you are in a position of unsafe by default unless you take every possible protection measure.

        • Yeah, but opening an html file from a web server with a text editor doesn't mean that the javascript in the file will do anything other than be displayed in the text editor.

          We're not talking about integrating scripting engines or even anything that would follow links to other sources. Just plain old accessing files in any location with any program as if they were locally stored.
    • by Tim C ( 15259 )
      Every time you add features you add potential exploits. All you can do is make it as secure as you are able to, and be pro-active with regard to looking for and fixing exploits.
    • In a word, NO. (Score:3, Insightful)

      by WindBourne ( 631190 )
      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.
  • Ive always enjoyed kde. It has a lot of customization options and works quite well.

    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...

    • Hmm. My P3/600, 128MB ram, from the point of having the SCSI drives spun up (which happens in the BIOS setup), boots to a console login prompt, then has KDE up and running in about 1.5 minutes if I login immediatly and startx. If I ran something to use a graphical login, it would probably be slightly less. Kernel 2.6.7, Debian kept-mostly-to-the-bleeding edge
      • ack, someone interrupted me and i hit submit.. oops. Wanted to add, that same machine takes over 3 minutes to boot Windows '98 into a viewable state (and takes another thirty seconds after i can see everything before it starts responding), and 4 minutes with Win XP.
        • Combining your messages:

          My P3/600, 128MB ram ... takes over 3 minutes to boot Windows '98 into a viewable state

          If that's the case, you've either seriously messed up your computer with spyware and viruses, tried loading a thousand programs at boot, or you've got a nasty hardware problem, like a failing drive or defective memory. Seriously, there's no reason why Win98 should be taking that long to boot up.

          I just finished cleaning up my sister's Win98 machine, which is a P2-233 with 64MB of memory, and i

    • 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
    • However you'll have little need to keep rebooting your box with linux/kde as opposed to the instability of windows. A (vastly) more stable OS is a good tradeoff for a slower boot time (since the days of OS/2); any (little) time you "waste" booting is more than offset by the several times you'll have to reboot windows in the same day.
    • The one thing that I do not like about it, is how long it takes to boot.

      (shrug) I usually boot my linux boxes every year or so, and never really thought about booting times being a problem... If you really want a fast boot, there is a linux bios project that allows a system to come from a powered off state to "ready for login" in a few seconds...
  • by FortKnox ( 169099 ) on Friday October 29, 2004 @03:14PM (#10666937) Homepage Journal
    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.
    • That's a very biased opinion from someone who obvioudly doesn't use KDE much. I find KDE miles more usable (as a desktop) than Windows. Using Windows is an exercise in frustration for me, and not being able to change it to some sane behaviour is even worse.
      • And that's a very biased opinion from someone who obviously doesn't use Windows very much.

        (See how easy that is? How is this "Insightful"?)
    • Actually, I find KDE a whole lot more friendly than windows. It might be because I have been using it for a very long time, but when I go back to windows, I simply don't understand how/where the options and controls are located.

      Compare a usable windows machine (with applications actually installed so you can do your job) with a stock KDE install (where you can still do your job). The menus have a much better organisation in KDE. Graphic-related programs are grouped together, and so are multimedia, devel

  • Don't forget DCOP (Score:5, Interesting)

    by nacs ( 658138 ) on Friday October 29, 2004 @03:14PM (#10666942) Journal
    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 [ibm.com] system integrated into KDE. The protocol handlers and DCOP can and do make a powerful combination.
  • by pschmied ( 5648 ) on Friday October 29, 2004 @03:18PM (#10666983) Homepage
    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
    • Don't know about the Mac, but Window's shell (explorer) makes it fairly easy to write extensions. There's already one for WebDAV, for example, and a coworker once wrote a windows shell extension for file browsing over ssh, using pscp [tartarus.org] (or plink, I don't remember) to take care of the underlying ssh work. Surely someone could do the same for the Mac?
    • by Wesley Felter ( 138342 ) <wesley@felter.org> on Friday October 29, 2004 @03:48PM (#10667313) Homepage
      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.
      • FUSE KIO Gateway (Score:3, Informative)

        by dmaxwell ( 43234 )
        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.

        Not necessarily.....

        http://kde.ground.cz/tiki-index.php?page=KIO+Fus e+ Gateway
      • but Apple is doing it right by integrating network resources into the real VFS layer so that all applications can access them.

        If you mean the kernel VFS layer, then Apple is not doing it right: this sort of functionality does not belong in the kernel. And Apple has not even managed to make the Carbon and Cocoa views of the world entirely consistent.

        KDE's I/O slaves are not real filesystems and are not accessible by all applications.

        True, and that is bad. But there is a middle ground between KDE's pi
    • Forget new protocols, I'd really love for things like ftp:// and smb:// and WebDav to work reliably without forcing me to force-restart the Finder every time I try to use one of them ...
  • Pretty slick (Score:5, Insightful)

    by Boarder2 ( 185337 ) on Friday October 29, 2004 @03:18PM (#10666986) Homepage
    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)
  • 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
  • useless protocols? (Score:4, Informative)

    by JBdH ( 613927 ) on Friday October 29, 2004 @03:24PM (#10667050)
    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.
    • by Hooded One ( 684008 ) <hoodedone@[ ]il.com ['gma' in gap]> on Friday October 29, 2004 @03:49PM (#10667321) Journal
      Staikos sort of hinted at this in the article when he mentioned that pop3:/ isn't terribly useful in a web browser and is more designed for internal use. You can use pop3:/ for easy inclusion of POP support in an app you're writing. Sure, you could use a POP library directly, but the point of abstraction layers like this is to make things easier and more consistent.

      The key advantage of KDE's IOSlaves over protocol handlers in Windows is that in KDE they are transparent and available to every application. This is not the case in Windows or OSX. Gnome-VFS does have this advantage as well, but is nowhere near as extensive.
  • Old Unix philosophy (Score:5, Interesting)

    by glassware ( 195317 ) on Friday October 29, 2004 @03:28PM (#10667093) Homepage Journal
    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.

    Correct me if I'm wrong, but wouldn't the old way of doing this be something like /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.

    What was the reason for not implementing these as devices?
    • by Anonymous Coward
      The reason would be that devices are specific to the OS, whereas KDE is designed to run on multiple UNIX-like platforms.

      In fact there is a module for the FUSE system that allows you to use the KDE plugins in the way you suggest.
    • by Brandybuck ( 704397 ) on Friday October 29, 2004 @03:55PM (#10667383) Homepage Journal
      What was the reason for not implementing these as devices?

      Because KDE is a cross platform desktop, and devices are too tightly tied to a specific kernel. A Linux device doesn't help a FreeBSD, Solaris or AIX user.
  • by Dante Shamest ( 813622 ) on Friday October 29, 2004 @03:33PM (#10667130)

    ...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.

  • wrong layer (Score:4, Interesting)

    by DrSkwid ( 118965 ) on Friday October 29, 2004 @03:36PM (#10667161) Journal

    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 /dev/usb1/1/data

    grep bunny /n/ftp/pub/*/readme

    etc.
    • by Anonymous Coward
      cat perldoc://someuri/perldoc1
      I see the problem, you should have used the "kat" command...
    • Yeah, if you want transparent access across the whole system, you need it at the filesystem level. That would be one of the possible advantages of, say, the Reiser4 filesystem.

      Now, as you may or not recall, a couple months ago there was a giant flamewar on the Linux kernel mailing list about Reiser4, files-as-directories, plugins, and all the stuff that would make such things transparent at the filesystem level, and the net result was, "it's not going in right now."

      KDE programmers aren't kernel hackers, a
    • Re:wrong layer (Score:3, Interesting)

      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 /dev/usb1/1/data

      grep bunny /n/ftp/pub/*/readme

      etc.


      Sure, no problem. [ground.cz] It's still a work-in-progress, though.
      • Re:wrong layer (Score:3, Informative)

        by Ice_Balrog ( 612682 )
        No, but you can "kwrite perldoc://someuri/perldoc1" (or any other program that supports kioslaves).

        I don't see why this has to be at the kernel level - why not just make programs that use kioslave functions instead of open() (or whatever)? Not only that, but some protocols are very slow or don't work with directories well, and wouldn't be sutable to be treated like local folders. Putting this in the kernel is asking for a lot more root (and not just user) exploits. And finally, everything that uses tradi
  • by jlrobins_uncc ( 136569 ) on Friday October 29, 2004 @03:39PM (#10667194)
    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 .
  • I remember when I recently tried webdav://mywebsite I was pleasantly surprised in KDE.

    I just recently installed "ubuntu" (gnome 2.6).. which I must say is a really nice looking slim UI/theme. All around good distro.

    But does gnome have integrated webdav support? I would think they'd be on the ball to mimic any lil kde features that pop-up.

    --Zaq
  • open up a blank tab in safari and type:
    x-man-page://some_command
    where some_command is the command you want to see. I get a man page in a terminal. In fact for any given URL registered on my box, I get the Right Thing(tm) happening.

    I use the Default App pref pane (http://www.rubicode.com/Software/) and thus have pretty fine control over what happens when various URLs are clicked/activated. Well, I can't make new ones, something about the craptacular IE vestiges that control URLs by default, maybe, I'm not s
  • Wha? (Score:2, Informative)

    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.


    Like what kind of catching up? Like this?
    KDE on Mac OS X [kde.org]
  • Don't be a hater (Score:5, Interesting)

    by FudgePackinJesus ( 444734 ) on Friday October 29, 2004 @03:45PM (#10667267)
    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.
    • Re:Don't be a hater (Score:5, Informative)

      by Per Wigren ( 5315 ) on Friday October 29, 2004 @05:18PM (#10668154) Homepage
      The fact of the matter is that on built in network transparency, KDE has no equal.

      Yes, the Amiga. Just put the file "ftp.device" in DEVS:, mount FTP: and every single application can now use say ftp://ftp.sunet.se/ as if it was a local disk. ftp.device was written in the early 90s but the backend technology was there in 1986...
  • Bloat Critics (Score:5, Interesting)

    by SyntheticTruth ( 17753 ) on Friday October 29, 2004 @03:47PM (#10667285)
    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.

  • by Stevyn ( 691306 ) on Friday October 29, 2004 @03:48PM (#10667301)
    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.
    • The advantage of tar:/ is not that joe average now can open tars in his web browser but that it can be invoked transparently by all apps. You click on a .tar.gz in konqueror and it opens like a regular directory, you do the same in kate because you need a text file from the archive and it treats it like a directory, you have an archive with images of your different trips you can open them like a directory in gwenview or any other kde image viewer. It's the same for any other protocol supported by kio-slaves
  • by Pedrito ( 94783 ) on Friday October 29, 2004 @03:56PM (#10667391)
    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.
  • Let me know when it's included in a kernel module, and I can use it from all my programs. Until then, it's just more crap in a bloated set of non-standard user libraries.
  • Virtual file systems have been around for a while, and they are useful: there really is little reason why something like WebDAV or even NFS should have to go through the kernel--it can be handled more efficiently in user code. But as long as they are implemented as part of these desktop environments, they are not used by enough software for users to actually rely on them.

    What is needed is for the Gnome, KDE, and libc developers to get together and talk about how to unify this functionality, break it out c

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Working...