[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: About UDS_LOCAL_PATH and UDS_TARGET_URL, and how they used.
From:       Weng Xuetian <wengxt () gmail ! com>
Date:       2011-10-10 11:31:33
Message-ID: 3244575.5cQ9uQ5Okr () saber-chakra
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


在 2011年10月10日 星期一 12:14:52，David Faure 写道：
> 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.gi
> > t&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 :-)
> 
Emm, actually I didn't say it not works, but it has some problem. (Not only my 
little kio, but also desktop:/ )
Let me show a case:
1. Create a empty test file in desktop folder.
2. open kwrite, then use desktop:/ to open the file.
3. edit something
4. Save

The modified sign in kwrite title is not disappeared, seems kwrite thinks it 
fails to save, but actually it does. Same to my kio.

> > 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 :-)
> 
I think you are right, but for some case, I think the local path is required, 
but so it is application's work to determine this, right? Like what current qt 
applications's file dialog does.

> > 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?
> 
In Dolphin it works.
This case is like this:
1. open vlc
2. use open in vlc's menu
3. choose a file with nepomuksearch protocol.
4. vlc complains.

But I also wonder why desktop protocol works in this case... Seems 
nepomuksearch url get by filedialog cannot successfully do KIO:stat
["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]