Re: Old change in wallpaper index?

>
> Getfundamentals does get the wallpaper index always even if wallpaper
> was not selected.  An up to date wallpaper index is needed for other
> modules
> such as phonebook so that pointers to images use the correct index number.
> The index will also have information like origins.


OK, that helps.

...

This is my understanding of how it currently works for ringers (wallpapers
are exactly the same with differently dicts).

Two dicts are exchanged with the Phone objects in get/send data, "ringers"
and "ringer-index".
"ringer-index" is a dict of dicts. The keys in the ringer-index are the
indexes from the phone (e.g. the map files for LG phones) or a negative
number for new rigners not yet on the phone.
The dict referenced to by each index contains the base file name and origin
(optionally) of the rigner. This dict is used by the ringer widget to store
data and is written to the index file that gets stored in the ringer
directory.

The "ringers" is a dict containing the actual data read in from the file
system and is keyed via the base file name. Not all entries in
"ringer-index" have a corresponding entry in "ringers", e.g. builtin
ringers. This dict is only used for transfering data to and from the phone.

The GUI shows all the entries in "ringer-index" where the file existing in
the PC file system.

My plan for change to use the database for ringers is as follows:
1) Create a new dict for writing to the database that combines the old
"ringer-index" and "ringer" dicts. (I don't see the need to keep a separate
data dict now that everything is in the database.)
The attributes for this new dict are: name, origin, mediadata, short
(description), long (description), mimetypes, index (on phone) and
thumbnail. Some of the fields are optional (mediadata, thumbnail, index).
The idea is that all the info needed to display the image in the vidget will
be in the database, this will avoid the timedelay of having to query the
entire file from the database, write it out to tempfiles in order to obtain
the file info for the media type. This will give speed up initialising the
media views.
2) Convert the fileview/ringer/wallpaper classes to use this new dict
internally.
3) Provide conversion functions from the new dict to the old dicts, these
would continue to be used for send/get phone data and avoid having to change
all the existing phone code. It would also be used to automatically
upgrading from older versions of bitpim.
Index only updates will not discard existing mediadata if the riger is
already in the database, only the index attribute will be updated.

Comments? I've got a lot of this coded, writing the data to the database
seems to work well from a speed perspective I have not observed a
performance hit. The only downside so far is that the temp filename shows in
the media player when you double click on an item, and I can't think of a
way to delete the temp file after the player has finished other than
blocking bitpim until the player prcess terminates, and I don't like this. I
guess we could cleanup the temp files when bitpim shuts down.

Simon