|
|
|
|
kfmexec is launched when the user wants to open a remote file with
|
|
|
|
|
an application that only supports local files.
|
|
|
|
|
|
|
|
|
|
For this it does the following:
|
|
|
|
|
- downloads a remote file to a temp location
|
|
|
|
|
- starts a 'local' application with that temp file as argument
|
|
|
|
|
- wait fors application to be exited
|
|
|
|
|
- if the modification time of the file is different from the original one,
|
|
|
|
|
(because the file was modified) then it offers re-uploading the modified version.
|
|
|
|
|
This is how you offer network transparency to apps that don't have it.
|
|
|
|
|
|
|
|
|
|
BUT: with TDEUniqueApplication, this breaks, because the app returns at once,
|
|
|
|
|
so we have no way to know when the user finished editing the file...
|
|
|
|
|
|
|
|
|
|
Conclusion: if the application has network transparency built-in, it should
|
|
|
|
|
put "%u" in its desktop file - and kfmexec isn't used -. If it doesn't, either
|
|
|
|
|
it's a TDEApplication and kfmexec does its job, or it's a TDEUniqueApplication
|
|
|
|
|
and... kfmexec can't see modifications to the file. Be warned.
|
|
|
|
|
|
|
|
|
|
From Waldo: "The program doesn't return _at once_. It returns
|
|
|
|
|
after "newInstance()" returns. So if you open the file there it will still work.
|
|
|
|
|
(Or rename it)"
|
|
|
|
|
|
|
|
|
|
David Faure <faure@kde.org>
|
|
|
|
|
20-May-2000
|
|
|
|
|
|
