Re: [E-devel] File Manager File Handlers in E17

[Christian K. <kre...@in...>]

Hi Bobby,


bo...@sy... wrote:
> 
> Hi,
> 
>         Below is a patch for E17 that adds support for launching
> files in e's file manager.  I used the same db's that are currently used
> for icon data.  You are able to have multiple modifiers for a single file
> type.

thanks for the patch, I just had a look at it and here's what I'm
thinking: good work, but I think there are two problems with your patch:

o  It's bad to combine the icon definitions with the filetype handlers.
It would be nice if people could just swap the icon set that they're
using without affecting anything else. Logically, filetypes and not
icons are mapped to file handlers.

o  If you base the handler lookup on a specific icon's db instead of the
filetype, you lose the chance of making the lookup "prefix-based",
therefore you need to add a lot of redundant handler definitions (you're
specifying feh six times in your script). It's great to be able to, say,
use feh as a generic handler for everything "/image" and gimp as the
handler for "/image/xcf", we'll definitely support that. But it should
also be simply to just specify one handler for everything "/image".

Therefore, the handler lookup will need to be a bit more flexible. Say a
file has type /a/b/c, then you'll need a traversal of the tree of
filetypes from the root to the filetype and remember the best-matching
handlers you find: check for a handler for /a. Say it's app_a. Check for
a handler for /a/b, maybe nothing is defined. Check for /a/b/c, with
app_abc. Then pick app_abc as the handler. If there's nothing for
/a/b/c, then fall back to app_a.

I'd define this in a separate db, simply listing the filetypes and their
handlers as key-value pairs. It will need to be read in and put into a
simple tree datastructure. The tree is going to have a large fan-out on
the first level and will be fairly shallow afterwards, so it might be
worth using hashtables for the first lookup (then again, it's probably
not worth it -- I think the threshold for using hashes is currently
assumed to be at lists of roughly 30 items, that's a lot of handlers...)
The lookup results then should be cached in a different hashtable
anyway.

For distribution of that handlers db, we should also be able to define a
list of handlers with different priorities to make sure to be robust if
a user hasn't installed an app. Just as an example, say 1. feh, 2.
entice, 3. eog, 4. xv.

So all in all it's a bit tricky :)

The idea with the modifier keys is nice. I'd probably put that in a
submenu though, as efm did: right-click on a file -> "Open with ..." -->
pick your choice.

Cheers,
Christian.
-- 
________________________________________________________________________
                                                    http://www.whoop.org