[Bitpim-devel] Media selection lists in phonebook entry editor

[Stephen Wood]

getfundamentals returns listings of wallpaper and ringers available on
the phone. These listings are arrays, where the index of the array is
apparently the number that you need to tell the phone (in the pbentry
packet in the lg case) in order to get it to use the wallpaper or ringer
associated with that index.

Also it is my understanding, that every file that is going to be
retrieved from the phone in the getwallpapers or getrintones methods,
must be returned in the indexes made by getfundamentals.

Assuming, that I have got the above right, the problem with the Sanyo
phones is that not all of the available ringers and wall papers can be
assigned from BitPim. This because either,

1. I haven't figured out the protocol to get the index for some files,
or how to tell the phone to use that file.

or
2. There is simply no way for some files to be assigned to phone book
entries. I believe that this is the case for camera pictures. (Camera
pictures can be assigned to phonebook entries using the phone itself.
What happens is that the act of assigning a camera picture to someone
causes a small version of the file to be made.)

So for these files that I don't know how to assign, but still want to
allow downloading, I would like to signal to OnListRequest in
wallpaper.py and ringers.py, not to publish them to the phonebook entry
editor.

What is the best way to do this? It seems the choices are either to
use negative very large indexes, or to add an attribute like
'notselectable' to filenames I don't want to showup in the phonebook
entry editor. Suggestions?

Stephen

[Roger Binns]

Post by Stephen Wood
getfundamentals

Initially the point of getfundamentals was purely to get information
that would later be useful to getting any of the other information.
As a simple example, the phonebook entries point at ringtone
indices, and you would need the "fundamental" information to convert
that back to a string. Similarly the ESN (or an id based on it)
would be used wherever serials have to be generated.

Similarly getfundamentals is also used when writing, mainly to
assist the convertphonebooktophone routine which would need
information from the phone to do some of the conversion.

Post by Stephen Wood
returns listings of wallpaper and ringers available on
the phone. These listings are arrays, where the index of the array is
apparently the number that you need to tell the phone (in the pbentry
packet in the lg case) in order to get it to use the wallpaper or ringer
associated with that index.

They are actually dicts, and the dict key means nothing.
In the LG case it is used between the call from getfundamentals
and then in getphonebook to do the number to name conversion,
as well as in convertphonebooktophone to do name to number
conversion.

(You are guaranteed that the keys will not change from the first
call to getfundamentals though calls such as getphonebook, getwallpaper,
convertphonebooktophone, savephonebook etc, but once the data
arrives in BitPim the keys may be changed to suit the purposes
of the underlying storage).

For writing something similar happens. So the meaning of the number
is private to the phone specific code, and may be different
than how BitPim actually stores it.

To a certain extent the BitPim data structures for phonebook
entries, wallpaper indices etc look too complicated. They
are dicts, containing dicts. Instead of having random numbers as
keys for the outer dict, it could just be a list. However there
are two reasons for this "design". One is historical in that it
was how best to deal with LG VX4400 stuff originally, and the
other is that at some point BitPim will have to start using
some form of embedded database for storing all the information.
When using the database, each record will need a unique key
and that is what the number will be used for. The number will
not be special to any phone.

Note that the phonebook entries store the wallpaper/ringtone
information by name only, no numbers are involved.

Post by Stephen Wood
Also it is my understanding, that every file that is going to be
retrieved from the phone in the getwallpapers or getrintones methods,
must be returned in the indexes made by getfundamentals.

I think that is the case, although you can work around it.
The wallpaper-index is used to give the list of choices to
to the user in the phonebookentryeditor. Consequently it
can include entries that BitPim doesn't have the image for
such as builtin wallpapers.

Post by Stephen Wood
Assuming, that I have got the above right, the problem with the Sanyo
phones is that not all of the available ringers and wall papers can be
assigned from BitPim.

That is a fairly tricky situation to handle. I believe that any downloaded
media has to be in the index in order to be displayed in the wallpaper/ringtone
panels, so just leaving it out of the index will create issues.

Post by Stephen Wood
1. I haven't figured out the protocol to get the index for some files,
or how to tell the phone to use that file.

That will be solved in time, and may become point 2. I don't think anything
should be done yet until you know for certain.

Post by Stephen Wood
2. There is simply no way for some files to be assigned to phone book
entries. I believe that this is the case for camera pictures. (Camera
pictures can be assigned to phonebook entries using the phone itself.
What happens is that the act of assigning a camera picture to someone
causes a small version of the file to be made.)

In theory could you create the thumbnail yourself?

Post by Stephen Wood
What is the best way to do this? It seems the choices are either to
use negative very large indexes, or to add an attribute like
'notselectable' to filenames I don't want to showup in the phonebook
entry editor. Suggestions?

The index numbers can't be used for reasons mentioned earlier. I
think adding a 'selectable': False attribute is the best solution.
(I hate stuff that uses negative named keys and then boolean values :-)
However this should only be done once you know #1 can't be done.
It does mean that people can try and assign media to phonebook
entries that won't work, and your convertphonebooktophone should
gracefully handle that.

Incidentally here are some fragments after reading the index from
a VX6000:

result['wallpaper-index']={
1:
{
'name': 'Beach Ball',
'origin': 'builtin',
},

2:
{
'name': 'Towerbridge',
'origin': 'builtin',
},
13:
{
'name': 'clipboard2.bmp',
'origin': 'images',
},
131:
{
'date': (2003, 12, 11, 0, 6),
'name': 'pic01.jpg',
'origin': 'camera',
},

203:
{
'name': 'love_you_cat_sm.jpg',
'origin': 'mms',
},

Roger