[BitPim-devel] Old change in wallpaper index?

[Simon C]

Roger,

Do you remember the reason for the change to update the wallpaper index even
when it was not request in gui.py, log number 693.
I cannot see what the purpose is and I suspect that it is not required due
to massive change since then, I'd like to remove updateindex function, it is
functionaly equivelent to populate in the ringer and wallpaper widgets.
I am a little concerned that storing the filedata in the database instead of
the filesystem could cause the data to get wiped out by this function call,
if it is ever used, if it is no longer required it should be removed anyway.

Simon

[Roger Binns]

Post by Simon C
Do you remember the reason for the change to update the wallpaper index even
when it was not request in gui.py, log number 693.

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.

Roger

[Simon C]

Post by Roger Binns
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

[Stephen Wood]

On 5/3/06, Simon C <***@bitpim.org> wrote:
...
...
A couple of things this discussion may or may not relate to.

1. Many phones will often have two copies of a photograph. One that is
full size and one that is resized and assignable to contacts. Sometimes
these will have the same name and I resort to hackery in the driver to make
sure that they get different names in BitPim. (So that one or the other
doesn't get clobbered.) Is there something we can do so that the driver
does not need to worry about name collisions.

2. Sometimes pictures or ringers can not be asigned to contacts in BitPim.
This could be because they are full photos from the phone, or because the
phone protocol (at least to my understanding of it) lacks the ability to
associate that particular file with the contact. Can I make the index
number negative to keep such files out of the BitPim menu for associating
ringers and wallpaper with contacts?

Stephen

[Simon C]

Post by Stephen Wood
1. Many phones will often have two copies of a photograph. One that is
full size and one that is resized and assignable to contacts. Sometimes
these will have the same name and I resort to hackery in the driver to make
sure that they get different names in BitPim. (So that one or the other
doesn't get clobbered.) Is there something we can do so that the driver
does not need to worry about name collisions.

This will change in the new code. The name of the wallpaper will only need
to be unique within the origin it is in. So you could have a "camera_raw"
origin and a "camera_assignable" origin with images with the same name. Will
this work for the scenario you describe?

2. Sometimes pictures or ringers can not be asigned to contacts in BitPim.

Post by Stephen Wood
This could be because they are full photos from the phone, or because the
phone protocol (at least to my understanding of it) lacks the ability to
associate that particular file with the contact. Can I make the index
number negative to keep such files out of the BitPim menu for associating
ringers and wallpaper with contacts?

There is a hack of unknown origin in the code for this. I had not intended
to fix it.
Currently only ringers with an origin of "ringers" or "builtin" are
assignable to contacts.
All wallpaper except those with an origin of "video" can be assigned.
The wallpaper index has real meaning on LG phones so it can't be changed.
How about adding a couple of tuples to the phone profile of
wallpaper_origin_exclude_from_contacts("raw_camera", "video", "mms")
ringer_origin_exclude_from_contacts("sounds", "mms", "mp3s")


Simon

[Stephen Wood]

Post by Stephen Wood
1. Many phones will often have two copies of a photograph. One that is

Post by Stephen Wood
full size and one that is resized and assignable to contacts. Sometimes
these will have the same name and I resort to hackery in the driver to make
sure that they get different names in BitPim. (So that one or the other
doesn't get clobbered.) Is there something we can do so that the driver
does not need to worry about name collisions.

This will change in the new code. The name of the wallpaper will only need
to be unique within the origin it is in. So you could have a "camera_raw"
origin and a "camera_assignable" origin with images with the same name. Will
this work for the scenario you describe?

It will work great. Perhaps we can make origin names like "camera_fullsize"
and "camera_thumbnail" or such to make it clear which is the better photo.
Roughly, the phones seem to call the original photos "Review" and the
thumbnails "Saved to Phone", masking the fact that the "Saved" photos no
longer have the original resolution.

Also, the reduced photos are not necessarily assignable (through BitPim)
because I havn't figured out how to assign them on the Sprint Sanyo and
Samsung phones I have worked with. (But I just came across a comment by Joe
from ages ago that described how he did assignments for his Verizon Samsung
that I need to try with my Sprint one.)

Post by Stephen Wood
How about adding a couple of tuples to the phone profile of
wallpaper_origin_exclude_from_contacts("raw_camera", "video", "mms")
ringer_origin_exclude_from_contacts("sounds", "mms", "mp3s")

Something like that would work and be better than any hack I would come up
with.

Stephen

[Simon C]

Post by Simon C
This will change in the new code. The name of the wallpaper will only need

Post by Simon C
to be unique within the origin it is in. So you could have a "camera_raw"
origin and a "camera_assignable" origin with images with the same name. Will
this work for the scenario you describe?

It will work great. Perhaps we can make origin names like
"camera_fullsize" and "camera_thumbnail" or such to make it clear which is
the better photo. Roughly, the phones seem to call the original photos
"Review" and the thumbnails "Saved to Phone", masking the fact that the
"Saved" photos no longer have the original resolution.

The names of the origins are not restricted and you can use anything you
want, but, as com_phone suggests, we should come up with a naming
convension. "camera" is used currently and I don't think we should change
it. On all the phones I've used people can assign 'camera' images to
contacts.
I like "camera_fullsize", I'll add it to com_phone as the 'recommend' naming
convension for this type of image.

Simon

[Stephen Wood]

Post by Simon C
convension. "camera" is used currently and I don't think we should change
it. On all the phones I've used people can assign 'camera' images to
contacts.
I like "camera_fullsize", I'll add it to com_phone as the 'recommend'
naming convension for this type of image.
Simon

Sounds good.

Stephen

[Joe Pham]

Post by Simon C
Two dicts are exchanged with the Phone objects in get/send
data, "ringers" and "ringer-index".

We may be talking apples and oranges, but I thought the dicts are 'ringtone-index' and 'ringtone', 'wallpaper-index' and 'wallpapers'.

In any case, I don't see a whole lot of differences in storing these in the DB or text files. Either way would work fine with me. However, if you do store them in the DB, the data structure must be flexible enough to accommdate new/other fields.

With all things being equal, I'd also prefer storing the media data in files instead of in the DB, as Roger suggested.

-Joe Pham



_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Simon C]

Post by Joe Pham

Post by Simon C
Two dicts are exchanged with the Phone objects in get/send data,
"ringers" and "ringer-index".

We may be talking apples and oranges, but I thought the dicts
are 'ringtone-index' and 'ringtone', 'wallpaper-index' and
'wallpapers'.

Yes, that's what I meant.

Post by Joe Pham

Post by Simon C
In any case, I don't see a whole lot of differences in

storing these in the DB or text files. Either way would work
fine with me. However, if you do store them in the DB, the
data structure must be flexible enough to accommdate new/other fields.

You can see how I did this in the skyjunk branch in fileview.py. I used a
similar mechanism to the other database storage functions.
I'm going to store the data on the filesystem in a directory named the same
as the database file (without the extension). The current code puts the
blobs in the database.

Simon