[Bitpim-devel] Samsung SCH-A670 Update

[d***@netzero.com]

Got my hand on a A670; finally understood what Vic was talking about. Made changes to the code for some improvments. Things that currently work:
- Phonebook get/send including wallpaper & ringtone assignments (kept the mapping from Alias to URL that Vic made)
- No changes made to calendar as it's been working ok.
- Wallpapers ('My Image') download & upload, camera pix ('Gallery') download. Kept the 'date' dict entry Vic previously added for camera pix. Wallpaper index works correctly now.
- Ringtones download & upload. Ringtone index works correctly now.

Things that do not work, yet:
- Cannot delete camera pix (should users be able to?)
- Cannot upload camera (Gallery) pix. (should users be able to?)

Things that are kinda weird:
- After users upload wallpapers, the phone will reboot. After the phone rebooted, users must manually 'browse' the wallpapers in order for the internal index file to be properly updated. Have no idea why.
- The wallpapers resolution is currently set to 128x96 (max 128x160) in bmp format so that they can be used in phonebook assignments. Should we switch to 128x160 png format and let users use the file system for 128x96 bmp files?

More to come.

-Joe Pham


________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give

[Roger Binns]

Post by d***@netzero.com
- Cannot delete camera pix (should users be able to?)
- Cannot upload camera (Gallery) pix. (should users be able to?)

Implement them if you want to. For the VX6000 I only did download.
The reason was because the files had a name, there are two other
index files referring to file numbers and bitmap-ish index as well.
It would be very easy to confused as to exactly what the file name
is, what the user thinks it is, and if it was the same file as
last time. So I just stayed out of sending images back to the
camera section since that would remove any possibility of screwing
things up :-)

Post by d***@netzero.com
- The wallpapers resolution is currently set to 128x96 (max 128x160)
in bmp format so that they can be used in phonebook assignments.
Should we switch to 128x160 png format and let users use the file
system for 128x96 bmp files?

Every image can/should have an origin field. You should set this
when reading from the phone, and obey it when uploading back
to the phone. Users will soon be able to edit it.

Currently the Profile just has static numbers and format for
images. Once the origin field becomes user changeable the
intention is for the profile to have a function.

The function will be passed the origin field and the current
image size/format. It will then return what should should be
done in terms of conversion.

Roger

[d***@netzero.com]

Post by Roger Binns
So I just stayed out of sending images back to the
camera section since that would remove any possibility of screwing
things up :-)

Good idea. I'll follow your lead and stay out of it too.

Post by Roger Binns
Every image can/should have an origin field. You should set this
when reading from the phone, and obey it when uploading back
to the phone. Users will soon be able to edit it.

That's the problem, in this case the origin fields are currently both the same ('wallpaper').

Post by Roger Binns
The function will be passed the origin field and the current
image size/format. It will then return what should should be
done in terms of conversion.

It would not have helped in this case (unless we have something like wallpaper-lowres and wallpaper-hires for origin values). I was thinking of some sort of multiple/dynamic resolutions/formats in the phone profile. Any suggestions, ideas?

-Joe Pham



________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give

[Roger Binns]

Post by d***@netzero.com
That's the problem, in this case the origin fields are
currently both the same ('wallpaper').

You control what they should be :-)

Post by d***@netzero.com
It would not have helped in this case (unless we have something
like wallpaper-lowres and wallpaper-hires for origin values).
I was thinking of some sort of multiple/dynamic resolutions/formats
in the phone profile. Any suggestions, ideas?

You implied there were two mutually exclusive uses for the wallpaper.
I would make the most common one be an origin of "wallpaper" and
the other one be more specific "wallpaper-frontscreen" or "wallpaper-phonebook".

In general I have taken the approach of doing whatever will
least surprise the user, make the media items most usable,
and result in the least number of questions on the mailing
list. Very rarely someone will complain about how image
they lovingly crafted into a particular size and format
got mangled by BitPim (Hi Vic :-), but for every one of
those, thousands just happily use them blissfully unaware
of these kinds of detail.

Roger

[Vic Heintz]

- Vic

Post by d***@netzero.com
Got my hand on a A670; finally understood what Vic was talking about.
Made changes to the code for some improvments. Things that currently
- Phonebook get/send including wallpaper & ringtone assignments
(kept the mapping from Alias to URL that Vic made)
- No changes made to calendar as it's been working ok.
- Wallpapers ('My Image') download & upload, camera pix ('Gallery')
download. Kept the 'date' dict entry Vic previously added for camera
pix. Wallpaper index works correctly now.
- Ringtones download & upload. Ringtone index works correctly now.

Thanks Joe. It probably took you a fraction of the time it would have
taken me to make those fixes.

Post by d***@netzero.com
- Cannot delete camera pix (should users be able to?)
- Cannot upload camera (Gallery) pix. (should users be able to?)

Users would like to upload upload random jpegs into the gallery because
the wallpaper dir is limited, but adding the correct 96 byte header
would be tricky. I'm OK with the no delete. However,one thing I was
considering doing was making the camera pix wallpaper gets be an "add"
and not a "replace" operation. If a user tends to keep a lot of camera
pix on his phone, it is a nuisance to have to wait for the
re-downloading of a bunch of images that already exist.

Post by d***@netzero.com
- After users upload wallpapers, the phone will reboot. After the
phone rebooted, users must manually 'browse' the wallpapers in order
for the internal index file to be properly updated. Have no idea why.
- The wallpapers resolution is currently set to 128x96 (max 128x160)
in bmp format so that they can be used in phonebook assignments.
Should we switch to 128x160 png format and let users use the file
system for 128x96 bmp files?

Not sure what to say. The front display is 128 X 96, the full inside
one is 128X160 but the usable area is only 128X128 between the top row
of icons and the bottom row of menus. If the size is set to 128 X128,
what does BitPim do if you import a 128X96?

I noted in the p_samsungscha670.p file that you have:
max_ringtone_entries=40
max_image_entries=30

Did you change things to use these values? I once had these set this
way because these appeared to be the "theoretical" values based on what
I saw (as you probably did) in the index files:
ringtone_index_file_name='nvm/nvm/brew_melody'
image_index_file_name='nvm/nvm/brew_image'

However in practice the limits actually seem to be 20 and 10. Things
started acting weird if you exceeded these values. You better test this
out with your phones.

Vic

[d***@netzero.com]

Post by Roger Binns
the most common one be an origin of "wallpaper" and
the other one be more specific "wallpaper-frontscreen" or "wallpaper->phonebook".

That's exactly what it is.

So you envision each phone model would define its acceptable wallpaper types/origins in the phone profile along with asscoiated resolutions and formats. Users would then be able to edit those origins and have the correct resolution and format image sent to the phone. That'd work for me!!

If you haven't already done it, what'd you think of the GUI should look like? I'm thinking it could be as simple as a combox box for the current origin field.

-Joe Pham


________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give

[Roger Binns]

Post by d***@netzero.com
So you envision each phone model would define its acceptable
wallpaper types/origins in the phone profile along with asscoiated
resolutions and formats.

There will be a list of origins in each Profile. The resolutions and
formats will be done via a function which is passed an image's current
size, format and origin. It will return what to do. This is to
cope with the phone supporting multiple formats - the function can
say to leave the image alone since it is fine as is.

Post by d***@netzero.com
If you haven't already done it, what'd you think of the GUI should look
like? I'm thinking it could be as simple as a combox box for the current
origin field.

I don't like the current 3 pane view, and am going to write a new display
at some point. See this message for my thinking:

http://article.gmane.org/gmane.comp.mobile.bitpim.devel/1204

The mockup screenshot shows the images arranged by type. The real
thing would add arranged by origin, and the origin would be mentioned
next to each image.

Roger

[d***@netzero.com]

Post by Vic Heintz
to make those fixes

I hope they worked ok for you.

Post by Vic Heintz
Users would like to upload upload random jpegs into the gallery

Understand the need, but as both Roger and you pointed out, the process could be tricky. Also, since the camera pix have different resolution and format (640x480 jpeg) than wallpapers, we'd need the editable origin feature that Roger described in his post to properly manage them.

Post by Vic Heintz
making the camera pix wallpaper gets be an "add" and not a "replace" operation

It's a good idea. I only have a few test snapshots on my phone so I haven't noticed that probem as much but I can imagine.

Post by Vic Heintz
If the size is set to 128 X128, what does BitPim do if you import a >128X96

It would send through as 128x96. As far as I can tell, BITPIM resizes images if they're 120% larger or 60% smaller than the specified resolution.

Post by Vic Heintz
in practice the limits actually seem to be 20 and 10

You're correct that I got those numbers from the sizes of the index files, but I trust your experiences more. Will revert the changes.

-Joe Pham


________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give