From: Henrik Backe <backe_at_swipnet.se>
Date: Tue, 13 Jan 2004 15:16:36 +0100

I've alreday done som work on the concept and hope te bee
able to show a "proof of concept" this weekend. I think
everything except the build system support for the view.config
file will be there.

"Daniel Stenberg" <daniel_at_haxx.se> wrote in message
>
> Viewing a File
>
> 2. Extension config file ".rockbox/view.config". A config file lists
> extensions and what plugin (file name) that should be ran to view
that
> particular file. This file is _not_ scanned at boot, but will be read
> and cached at first use. We could possibly have an option to parse it
> automaticly at boot.

cached where?
If it's cached in a separate file I can't see any performance benefits
at startup. My thinking is to read view.config at startup if it exist,
but also, make sure that no view.config is needed in a standard
setup (3. takes care of that)

>
> 3. Check if ".rockbox/viewer/[extension]-[anything].rock" exists, and if
it
> does: use that. These plugins _are not_ scanned at boot nor after USB
> disconnect.
>
> View Supported
>
> The concept of "view supported" files changes somewhat. Internally
supported
> formats are of course present, but extensions in the "view.config" are
> only supported once the file has been read and and so are extensions
that
> have been "verified to work". That means we've played one successfully
and
> thus there was a plugin for it in the proper dir.

I disagree slightly. This means that plugin supported files hardly ever will
be showed as supported. My thinking as that if an plugin exist for an
extensions
it should be shown as supported. When scanning the viewers directory
all supported extensions should be stored (only in RAM). This has the
advantage
that scanning only have to be done once.

I think there should possibly be an option to do this scan at bootup.
Playing view.config should also invoke this scan.

>
> Icons
>
> The 'view.config' file will have a field for this, see below for the
file
> format. (The icon can also be provided as a separate file next to the
> plugin, as in "[extension]-[anything].icon", but this will then make it
> suffer from the same drawbaks as the "view supported" have. The icon
> file should then use the same syntax as the icon field of the
view.config
> file).
>

I'm not so sure about saving the icons in view.config. It's ok for now but
The icon handling has a a large scope than just plugins.
If get many different icons fort tha same file (depending on font and/or
font size),
we will need separate icon files. But as you wrote, lets get this
implemented
and proceed with improvements later.

.../Henrik
Received on 2004-01-13