"look inside" context menu item

[David Faure]

On Monday 23 February 2009, Jos van den Oever wrote:
> 2009/2/23 David Faure <faure at kde.org>:
> > On Sunday 22 February 2009, Jos van den Oever wrote:
> >> 2009/2/22 R.F. Pels <ruurd at tiscali.nl>:
> >> > On Sun 22 February 2009 16.59.05 Jos van den Oever wrote:
> >> >
> >> >> The tricky bit is to formulate the Exec= part of the desktop file.
> >> >> When the action is called on 'file:/tmp/myarchive.zip', the action
> >> >> should open 'jstream:/tmp/myarchive.zip' in the same window. What
> >> >> would the action look like?
> >
> > The desktop file looks ok, but are you installing it into the right directory?
> > Looking at kdeutils/ark/app/ as an example, that would be ${SERVICES_INSTALL_DIR}/ServiceMenus
> 
> I did this. I took the ark desktop file from ServiceMenus as an
> example. I checked the paths with . The only thing I've not tries so
> far is logging out and logging in again. The path was checked with
> "kde-config --path services". I installed both in the system dir
> (/usr/share/kde4/services/ServiceMenus as well as my local testing
> prefix.

Tried `kbuildsycoca4`? (especially if you don't have the kded fix,
but you should, assuming a kdelibs >= r918838, 4.2 or trunk)

> >> There is a protocol for this:
> >> http://websvn.kde.org/trunk/playground/base/strigiplasmoid/src/jstream/
> >> It is more powerful than tar:/ and zip:/ because it can handle emails,
> >> rpm, ar, cpio and deb archives. In addition, it can recursively open
> >> archives.
> >
> > Interesting - does it also support writing? The highest wish assigned to me
> > right now is about that; https://bugs.kde.org/77127. I didn't look into how to do
> > it yet, I only noted that I should look at kio_p7zip, fuse-zip, krusader, and ark of course,
> > all of which can allegedly do it.
> libstreams has no writing support at all. Writing to recurse archives
> or to email attachments is a can of worms. So writing support would
> need to be added as  special case per archive format and not
> recursively. For write support there should be a way to call ark to do
> this.

Calling ark sounds very slow and cumbersome, this is definitely not the
best way to do this. Dropping or pasting a file into the view triggers a KIO::copy
with jstream as destination, the resulting copy() or put() in the slave should
handle the data, not launch another app and pass it the data and ensure
it doesn't pop up a window and then reload the archive... (!)

> > So this makes the situation even more complex; if it wasn't for writing then
> > your kio_jstream would sound like the perfect solution and I would have
> > recommended making it default (which is easier, see the "archiveMimetype" field
> > of the .protocol file)... so I think you're right, a RMB / look inside is probably a
> > better solution.
> Having only one archive kioslave would be great and kio_jstream is
> certainly the best for reading. For now however, I'd like to mature it
> in playground and not take on the responsibility of the writing part
> of an archive kioslave.

Two contradictory statements, unfortunately... if it's the "one and only"
then it should be feature-full... I don't mean right now of course, but if it's
not planned at all ever then we have to evaluate other solutions :/
Or maybe combine one of the solutions I mentionned into kio_jstream --
or into a class that it can use...

> My initial question has not been answered btw. What should I put in
> Exec in the desktop file action to get Konqueror or Dolphin to open
> jstream:/myurl when the original file has file:/mypath as url? It it
> even possible?

Not directly, just call a script that does the correct URL mangling and then calls
kioclient exec "$url" inode/directory
(to use the preferred file manager, which might not be konqueror)

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).