Rockbox mail archiveSubject: Re: Viewing Files With Plugins Proof of concept
Re: Viewing Files With Plugins Proof of concept
From: Henrik Backe <backe_at_swipnet.se>
Date: Tue, 20 Jan 2004 23:01:42 +0100
"Björn Stenberg" <bjorn_at_haxx.se> wrote in message
>Henrik Backe wrote:
>> I've made a few changes to this scheme.
>> - /.rockbox/viewers.config and /.rockbox/viewers are
>> read/scanned at bootup if no /.rockbox/.viewers.cache
>> exist. This way we always know what extensions are
>> supported, and we only get excessive file reads on the
>> first boot.
>Is this really necessary? Reading one file and one dir should not be much
slower than just reading one file.
>I would prefer to just have a single config file. This also simplifies the
It won't simplify the code much, the cache file and the viewers.config have
the same format.
And its in the simple format "extension,plugin,icon". The only difference is
that in the cache file
same additional plugins are stored (plugins from the scan of the viewers
folder, but are not associated
with any extension for example the upcoming id3 tag editor)
Also Daniel wanted an cace file, see item 2 in
>> - I've made the assumption that for example
>> txt-viewer.rock and viewer.rock will be in
>> the /.rockbox/viewers folder, and then no rocks with
>> an extension prefix should be displayed in the
>> onplay->"open with" menu.
>How do you mean?
According to Daniels scheme you can have several instances of the same
In this case it's only necessary to show viewer.rock in the "Open with"
>> - figure out a sane value for string_buffer in filetypes.c
>> It's set to 1000 bytes, but I think it can be reduced.
>Could you explain what you use it for? It's not entirely obvious.
I'ts a method I've used to keep downthe size of the tables built when
the config file/scanning the plugin directory.
Instead of having an array of arrays with rather large fixed sizes to store
and icons I have an fixed size arrays with pointer. to string_buffer where
strings. The viewers directory vill contain 8 rocks using Daniels build
and will use ~120 bytes of the string buffer.
>I think the plugin file config format should be simplified, from the
This format is only used when building the plugins, it will allow creating
form the same format. See Daniels mail
under the heading Build System
>to the more terse:
>chip8,ch8,70 70 7f 7f 70 70
>This simplifies the parsing code greatly, and speeds up loading too.
True, and thats actually the the format used.
(well not quite, its ch8,chip8,70 70 7f 7f, 70, 70)
>I also don't think it is necessary to verify that each plugin exists when
loading the config file. It's just as well to show an error >message when
the user tries to load it from the menu.
Received on 2004-01-20