On Monday 10 October 2011 14:20:51 Weng Xuetian wrote: > Hi all, > I'm trying do develop a small kio protocol, which can list all recent > document from KRecentDocument. And I'd like via this kio, recent document > can be edited, upload, or some else directly. > (code is here, not complete yet > http://quickgit.kde.org/?p=scratch%2Fxuetianweng%2Fkio_recentdocument.git&a= > summary ) > > So I try to use KDesktopFile to get the real url, and fill the UDS Entry > with UDS_LOCAL_PATH and UDS_TARGET_URL. But finally stuck here. I found > that from dolphin, the file can be correct opened with "Target Url". But if > I try to open anyfile in other program, such as kwrite, it seems that they > open it with the recentdocument:/ url.
Yes, since kwrite uses KIO, so it "supports remote URLs". > This is also happened in desktop protocol. If I want to open a file, such as > desktop:/a.txt, kwrite will get the file, but with url desktop:/a.txt, this > also makes kwrite "Save" behaviour incorrect (It can save, but the > "modified file" sign is not removed). So I would just stop here... I can > also think of that other KDE application's behaviour will be similar to > kwrite. So, if kio can find a file to be a "local file", should > applications themselves take care of this if they prefer local file. That's the issue. In your case you would "prefer the local file", but in the case of desktop or trash or any other procotol which aims at "hiding" the local file system, we don't want to show the local file path. This makes this whole thing tricky, when some kioslaves want something and others want something else... > Actually all my initial intention is to make openSUSE patched firefox can > use my little kio to upload files, I can patch the kmozillahelper to fix > it, but I wonder this is correct or not. Since there is still some problem, > like if a nepomuksearch is used in kwrite, kwrite still use the > nepomuksearch url, instead of the target url. > > After some investigation, I found the behaviour is different from program to > program, and from protocol to protocol, shoud there be standard, that how > shoud target url and local path be used. This two concepts really makes me > confused.... what will happen if local path and target url point to > different local files? I cannot imagine. Yeah that would be wrong :) My initial intent was: * UDS_LOCAL_PATH is used internally so that apps can resolve urls to local paths but without showing it to the user. This is how we can do direct reading of desktop files and direct mimetype determination etc. (e.g. in KFileItem) of urls that are in fact local internally. * UDS_TARGET_URL is "what URL should be opened when clicking on this file". E.g. KRun::run() uses targetUrl(), which proves this point. So I'm actually surprised by your test that says that kwrite ends up at recentdocument:/ -- ah it works from dolphin (which uses KRun), so please describe the case where it doesn't work. Obviously if you run kwrite, then Open, then type recentdocument:/, it will use that :-) > The best solution currently I can think of is, if file is local, > UDS_LOCAL_PATH should be set, no matter whether UDS_TARGET_URL is set or > not, seems kde file dialog in qt app can resolve this to local file (Since > mostLocalUrl in KFileItem only take UDS_LOCAL_PATH and real path into > account). For kde application, if they must use a local path instead of kio > they should resolve it themselves. Is this correct? No, with some protocols we want to hide local paths :-) > And for nepomuksearch.. is there a bug that vlc will complain "only local > path" in nepomuksearch (this is not happened in desktop:/ or my own little > recentdocuemnt:/ ). Would need investigation. I don't know if it uses UDS_TARGET_URL, I remember Trueg going back and forth about it. Is this when clicking on a file in dolphin? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
