The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Kioslave hell
by Andras Mantia on Saturday 28/Oct/2006, @12:49
|
There is no need for hacks over hacks, only right way of using the KDE API and creating the correct desktop files. But whatever, I tested media:/, system:/ and home:/ URLs with KDE and non-KDE applications mentioned here. Well, amarok, kaffeine, konsole, xine and openoffice has no problems. For those who doesn't understand the URL is translated to the real path. Eg. open a file in oowriter from home:/user and when you try to save it, you will see in the file dialog: "/home/user" as the current directory. I'd say they work unless you give a non-working example. And I'd say this proves that if they don't work, it's nothing else, but a bug.
Just for the record: self-compiled KDE 3.5.5 on SUSE 10.1.
Oh, and I like the media:/ slave (i don't use the others) as it is much easier to use and remember than some path that can be different on every distribution.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Saturday 28/Oct/2006, @17:07
|
The reason why some apps don't have problems any longer is that they've been hacked to either translate URLs or copy files to temporary locations etc. And these hacks need to be maintained, and new hacks will need to be written in order to accomodate new needs.
All of this just for the sake of having the same URL on all distros. And the distros already use the same URL, '/media'! Unless they're not FHS compliant (very old Linux? IRIX?).
And even if they did use different locations for mount-points (which they don't), what would be more important:
a. having URLs that can be understood by all apps on _your_ system, or
b. having URLs born incomprehensible (albeit partially resurrected by haunted application developers ;-) ) that look the same on all distros? Who cares about all distros?
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Andras Mantia on Sunday 29/Oct/2006, @00:29
|
Have you ever used the KDE API to write applications? If you stick to KURL everywhere you will have hard time to break media:/ or system:/ or whatever. It just works. And if you don't use KURL e.g because you have to pass the files to a non-KDE application (like xine) just use "Exec=appname %f" in you appname.desktop file instead of "Exec=appname %U" and KDE will download the file to a temporary location before passing to the application.
Really, there is no need for hacks unless in very few cases and even than it should be a minor issue to make it work. And for me both a and b is important and I would fix a rather than just throw away something because some apps have issues at this moment. But what apps, please tell me and I will test here as well...
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Morty on Sunday 29/Oct/2006, @02:04
|
The problem is that KURL does not really help you in most of the bugs caused by this, the remote IO-slaves have never been a problem. The problem are the unnecessary local ones like media:/. They have created bugs for every application that have the need for treating local files different then remote files. Lots of applications like Kaffeine, k3b, codeine etc have special handling of cases when these URLs are used to to make them be seen as local files. And none of these applications had this before being notified by a bug report. So it simply does not just work.
And it's not about throwing something away because some apps have issues, it's about throwing something away that does not give any benefit over the systems existing solution. And in addition it introduces unnecessary problems and create issues for applications. IO-slaves are great, but they are not the solution to everything.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Andras Mantia on Sunday 29/Oct/2006, @05:53
|
There is only one specific things with media:/ and co. they are local even if they don't look so. The only case when an application has to do something special is when it is a KDE application, uses KURL, but doesn't support remote operation. Why? Because if its a KDE application and uses only KURL inside it simply shouldn't care if the KURL points to a remote or local file. If it's a KDE application, but works only with local paths and uses QStrings to store paths, it should specify that it cannot open remote URL's (uses filename %f in the .desktop file). In case of non-KDE applications, the situation is the same.
So what is in the case of using KURLs and not supporting remote files? I think this was the case of Kaffeine, Amarok and K3B as all of them pass the paths to third party non-KDE applications who don't no anything about KIOslaves. Well, just check the sources for K3B for the "hack":
if( !url.isLocalFile() ) {
return KIO::NetAccess::mostLocalURL( url, 0 );
}
The hack you are looking for is "mostLocalURL". The function is there since KDE 3.5.0, released quite some time ago.
I simply don't buy the argument that this idea is broken and needs hack in the applications. In case somebody shows me real examples (none-working apps or extra hacks because of this) I can discuss more.
Another example is from amarok:
// Note: remove for kde 4 - we don't need to be hacking around KFileDialog,
// it has been fixed for kde 3.5.3
else if( protocol == "media" || url.url().startsWith( "system:/media/" ) )
{
...
}
So if there was a bug, it was fixed in 3.5.3. Bugs can exists, this is why they should be reported so they can be fixed either in libraries or applications.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Koos on Sunday 29/Oct/2006, @09:23
|
For KMPlayer, the mostLocalURL isn't such a nice solution. All KParts targeted for KHTML should not use local loops. The problem is that JS setTimeout() or other redirect ways, may fire inside such a local loop, causing a page reload. This will most certainly crash konqueror.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Andras Mantia on Sunday 29/Oct/2006, @09:59
|
I admit I never heard that you have to be so careful with KParts loaded inside KHTML, but in this case the problem is rather the hack used in NetAccess, than media:/ or mostLocalURL. This simply means you can never use KIO::NetAccess, right? I find this a particular case, wrong interaction between two applications, and in this case I admit a hack (or non-standard solution) is needed, like manually find out if it's a media:/ or whatever URL and translate yourself to the real path.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Sunday 29/Oct/2006, @16:33
|
> but in this case the problem is rather the hack used in NetAccess,
> than media:/ or mostLocalURL
From a pragmatic point of view it doesn't really matter whose fault it is. An unnecessary feature that triggers bugs in other features is still a mistake, no matter who has written the bugs.
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Leo S on Sunday 29/Oct/2006, @13:39
|
Look, I'm interested in use cases, cause that's where I run into these problems. As you mention, Kaffeine seems to be fixed, at least in Kubuntu 6.10 I can open a video file from media:/usbstick and it will work (it translates it to /media/usbstick, no idea what it would do on other distros that have no /media)
Here's a big one problem though. I plug in my flash drive, and want to get there in a konsole window. Now I could press F4 and it would work (on Kubuntu), but what if I have an already open konsole window? Intuitively I would type something like cd media:/usbstick. That obviously doesnt work. This would make no sense to users. Yes I know I can use some kde inbetween thing to do it, but I have no idea how, and if I did look it up, I would forget it immediately because it's so obtuse.
Now I want to open a file in helix player. If I open helix player and try to open a media:/ URL it won't work. Once again, this makes no sense to users. Why does a path that works in kaffeine not work in helix-player? Completely mystifying.
The point behind all this is that it causes very real problems for a very slight, if any gain. For some corner cases, the media:/ path is easier to understand, but for many more cases (anyone that doesn't use purely KDE software) it's a very big and very real problem.
In my mind, this is a poor tradeoff. Anyway, I've complained enough about this. Time to move on :) Well done Kubuntu for fixing this critical issue!
|
[
Reply To This | View ]
|
Re: Kioslave hell
by Gato on Sunday 29/Oct/2006, @16:30
|
Hm.
OK then you're right, there are correct ways of handling most parts of the problem. But why handle the problem and maintain that handling when it's far easier to not have the problem at all? Why not just use the standard filesystem?
|
[
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)
