faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Kioslave hell
by Morty on Saturday 28/Oct/2006, @06:23
|
You are missing the point, or points actually. Fixing the problems those IO-slaves create is not the problem, the problem is that they create those kinds of bugs in the first place for no gain whatsoever. They where supposed to bring some kind of usability improvment, which clearly they don't.
Nobody can argue that media://cdrom or system:/media/cdrom gives any kind of increased usability, compared to /media/cdrom or /mnt/cdrom. It's even worse with home:// since it points to /home rather than the users home, so instead of ~/myfile you have to use home://username/myfile.
The only things those IOslaves give are a possibility for subtle bugs, and breaking compability with legacy applications. They should be removed from svn as fast as possible, and never talked about again other than as examples of horrible usability mistakes.
The other IOslaves, like fish:// as you mentioned, does not have any of this problems. They are quite different in the way they provide extra functionality, not redefining already existing ones. Since OpenOffice is not able to edit remote files anyway, fish:// does not change anything or introduce a bug. While home://username/myfile.odt does, since its actually ~/myfile.odt a simple local file witch should be editable. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Kioslave hell
by anonymous coward on Saturday 28/Oct/2006, @06:36
|
Full ACK
I'm a huge fan of KDE's ioslaves except for media:/ which is driving me insane. Autodetection of removable devices is great and necessary, but the path which is given to applications should be /media. Everything else is simply broken.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by AJ on Saturday 28/Oct/2006, @13:10
|
> Nobody can argue that media://cdrom or system:/media/cdrom gives any kind of increased usability, compared to /media/cdrom or /mnt/cdrom.
It's way too Linux-specific. I'm used to /vol/local/dvdX for local and /vol/pool/dvdrX for drives at the server. media://dvd is much more simplier and just works, no matter which station you log on. Ok, maybe non-KDE apps have probs with this, but they can't handle fish:// as well.
> It's even worse with home:// since it points to /home
Yep, as that's what it is supposed to do. For your own home theres ~. But after you typed /users/bkoffice/8/bentruth a dozend times you'll start loving home://bentruth.
And no, I'm not running KDE as root, just Kate via sudo.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Saturday 28/Oct/2006, @16:57
|
> It's way too Linux-specific.
As someone else already reminded, being the same on all platforms is not always good. Java has swing which looks the same on all platforms. Some developers love this, but the rest of the people either don't know about other platforms, or they're at no advantage anyway. They only notice that it doesn't look as it should on their platform. This is why SWT was introduced, and this why I don't know of any successful Swing app.
So really, what's the point that I could (mis-)use the same non-standard URL on other operating systems? My problem is that it's non-standard on my system.
BTW, I'm a FreeBSD user, not a Linux user, and I too have /media and /home.
> I'm used to /vol/local/dvdX for local and /vol/pool/dvdrX
> for drives at the server.
You represent a very small minority that uses many machines with many different operating systems with servers that do removable media on a regular basis (most servers really don't). This is unlikely KDE's main target, and thus it's not a reason to invent imaginary filesystems.
> media://dvd is much more simplier and just works,
> no matter which station you log on.
That's easy, just create a "/dvd" symlink on all machines. You can even automate the process provided you can detect the OS from a shell script.
> Ok, maybe non-KDE apps have probs with this,
> but they can't handle fish:// as well.
Not just non-KDE, but KDE apps too, unless someone patches them to make them work. And maintains the patch, instead of doing cool stuff, and writes some more patches for the new monsters - you don't assume media:/, home:/ and system:/ will be the last of them, do you? Just wait for doc:/info that will point to /usr/share/info and system:/doc/info etc etc. (Don't worry, just kidding)
As for fish:/, fish is different because it introduces new functionality. Without the fish KIOslave there would be no fish at all ;-). But /media would be there anyway, so no need to replace it with something that doesn't work.
> But after you typed /users/bkoffice/8/bentruth a dozend times
> you'll start loving home://bentruth
Again, symlinks are your friends:
ln -s /users/bkoffice/8 /home
Besides, the file dialog has autocompletion so it's not that bad anyway. And inventing proprietary URLs just for the sake of shorthand is silly.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Debian User on Sunday 29/Oct/2006, @09:26
|
I am totally baffled at why you assume that every KDE system on earth should have /media or that the user will even be allowed to create it.
What KDE is and was for a long time already, or so I believe, is a desktop for a wide array of systems. One of its strengths being that the KDE framework solves the problems for the applications just fine.
My understanding is that media:// should work fine for every KDE application and that's OK. Where it does not, it's probably worth to note, that these apps have attempted to improve over the framework, so there is a need, point proven.
Stop telling KDE it should not provide its own ways of doing things. We actually like innovation around here.
Yours,
Kay
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Leo S on Sunday 29/Oct/2006, @13:20
|
>> I am totally baffled at why you assume that every KDE system on earth should have /media or that the user will even be allowed to create it.
The user doesn't create it. That's up to the distribution/system.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Sunday 29/Oct/2006, @16:37
|
> I am totally baffled at why you assume that every KDE
> system on earth should have /media
I don't assume that at all, I only assume that the fact that I have non-standard KDE URL (media:/) that just happens to be the same on other operating systems (that I don't use) is of no use to me.
(And I'm not just egoistically thinking about me, when I say "no use to me" it's just a way of speaking.)
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Sunday 29/Oct/2006, @16:41
|
> Stop telling KDE it should not provide its own ways of doing things.
> We actually like innovation around here.
By all means I'm not trying to tell KDE not to do. I'm not the one to do that, and besides I too like innovation. I'd like a KDE way of doing things, such as making hardware access 'just work', transparently to the user.
But media:/ and system:/ and home:/ are not new ways of doing things, they are just new ways of calling things. Same old things, new names, new misunderstandings, new breakage. Worst of all, new filesystems to learn. Real innovation would be getting rid of all filesystems in the user interface, not adding new ones on top of old ones.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by AJ on Sunday 29/Oct/2006, @10:03
|
> That's easy, just create a "/dvd" symlink on all machines. You can even automate the process provided you can detect the OS from a shell script.
Detecting the OS is not the issue - always the same. But "all machines" is wrong. There are only a few servers, 20 at the moment, but more than 300 Workstations. X session runs on the server, but drives are workstation-local. Good luck with symlinks... ;-) (kdm runs locally, reowns the drive to the user logged in and ncs a script on the server which automounts, kinda nasty but works)
> Not just non-KDE, but KDE apps too, unless someone patches them to make them work.
If they use the kio api, all kioslave should work or it's a bug to be squashed. I've never had probs with media:/ fish:// sftp:// or camera:/ (at home). system:/ or settings:/ are rarely used, ok, but they still work. audiocd:/ does, too.
> Again, symlinks are your friends:
> ln -s /users/bkoffice/8 /home
Bad luck. You'd have to link /users to /home (not everyone is in backoffice), but it wouldn't help. Not everyone has their homes in /users, but in /u (I'm there) or the Linux-like /home (for some local only logins).
> And inventing proprietary URLs just for the sake of shorthand is silly.
They are not proprietary, they're well documented and free to use (or ignored).
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Sunday 29/Oct/2006, @16:50
|
> They are not proprietary, they're well documented and
> free to use (or ignored).
There are at least two ways of speaking about proprietary. In one way you're right. But there's the other way: a method of software interaction can be called proprietary when it's free and open, but it's not an agreed upon standard and it requires special efforts from the part of other people in order to work.
This means that even if you give other people the tools to unbreak the compatibility that you have just broken, your URL language is still proprietary until it becomes an agreed upon standard.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by AC on Sunday 29/Oct/2006, @01:24
|
You write...:
Yep, as that's what it is supposed to do. For your own home theres ~. But after you typed /users/bkoffice/8/bentruth a dozend times you'll start loving home://bentruth.
If you'll allow using ~ for your own home, then how is home://bentruth any better than ~bentruth?
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
