Rockbox mail archive
Subject: Re: Viewing Files With Plugins UPDATED
From: Henrik Backe (backe_at_swipnet.se)
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
> 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.
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
> does: use that. These plugins _are not_ scanned at boot nor after USB
> View Supported
> The concept of "view supported" files changes somewhat. Internally
> 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
> have been "verified to work". That means we've played one successfully
> 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
it should be shown as supported. When scanning the viewers directory
all supported extensions should be stored (only in RAM). This has the
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.
> The 'view.config' file will have a field for this, see below for the
> 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
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
we will need separate icon files. But as you wrote, lets get this
and proceed with improvements later.
Page was last modified "Jan 10 2012" The Rockbox Crew