bitpim-devel — For bitpim developers

Re: [Bitpim-devel] Fwd: [Bitpim-user] BP.07-10 VX6000 Images

[Roger B. <ro...@ro...>]

> At least for the 4500, which is what I have, as I said I've been using
> it at 120x160 for a week or so.  

The size of the full screen is 120x160.  The only time the whole screen
is used for an image is the startup and shutdown images.  At all other
times there are information bars at the top and/or bottom of the screen.
If you use a 120x160 in those circumstances then it is clipped or shifted
by the phone.

You may want to make a zip file containing images at the various sizes
and put lines in every 10 pixels.  We can then try them on the phones
to see how they get shifted/clipped.

Roger

Re: [Bitpim-devel] Fwd: [Bitpim-user] BP.07-10 VX6000 Images

[Peter D. <du...@hd...>]

On May 17, 2004, at 12:56 PM, Roger Binns wrote:

> For which phone?  THe phones are not the same as each other and what
> works on one phone doesn't necessarily work on another.
>

At least for the 4500, which is what I have, as I said I've been using 
it at 120x160 for a week or so.  I notice that places offering 
wallpaper downloads bundle the 6000 and the 4500 together with 120x160 
downloads but I don't know that it works.

There is still the vx4500 wallpaper problem I mentioned before: when 
moving through the pictures with the "left and right" arrow it will go 
grey and shut down the phone when moving between two specific images, 
while going directly to an image always works fine.  I'll try to find 
time to look at that this afternoon.

Peter

Peter Dufault
HD Associates, Inc.

Re: [Bitpim-devel] Fwd: [Bitpim-user] BP.07-10 VX6000 Images

[Roger B. <ro...@ro...>]

Peter Dufault wrote:
> Any reason not to change to 120x160, Roger?  I maintain it that way
> locally for the VX4500.

For which phone?  THe phones are not the same as each other and what 
works on one phone doesn't necessarily work on another.

Roger

[Bitpim-devel] LG 4600 support

[Dale <dri...@te...>]

Hey Roger, here is the lastest error I am getting

AttributeError: 'pbentry' object has no attribute 'msgringtone'

Can I just comment this out from the code or is that a standard attribute
that the phone should have and I just need to update the length?

RE: [Bitpim-devel] Fw: VX4600 support

[Dale <dri...@te...>]

That is correct, I am Canada. 

-----Original Message-----
From: bit...@li...
[mailto:bit...@li...] On Behalf Of Roger Binns
Sent: Wednesday, May 12, 2004 5:22 PM
To: bit...@li...
Subject: Re: [Bitpim-devel] Fw: VX4600 support

Dale wrote:
> Here is the new log file. Here is the order the show on the screen , 5 
> phones number, 1 email, group,sound,memo field,wallpaper,not 
> secret,url

I have committed code that decodes your example entry, but you are going to
have to do some more experimentation.  Basically look in the protocol log,
change one thing, and see if it decodes the change correctly.

You should also make sure that various fields are the maximum length
possible. 

Do not try and write back to your phonebook yet (I would expect exceptions
anyway).

Incidentally, are you in Canada?  I think the way your phone is behaving is
what models with Java (J2ME) do.  If that is the case then the VX4600 you
have and the one Verizon has in the US will be different.

Roger


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for
SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Bitpim-devel mailing list
Bit...@li...
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Bitpim-devel] Fwd: [Bitpim-user] BP.07-10 VX6000 Images

[Peter D. <du...@hd...>]

Begin forwarded message:

> I've got some 120x160 pics on my computer that I wanted to put on my=20=

> phone.=A0 BitPim keeps converting them to BMPs and resizing to =
120x131.=A0=20
> I've even tried BMPs at 120x160 and they get resized also. Is it=20
> possible to stop the conversion to BMP?=A0 Why are the images being=20
> resized?

Any reason not to change to 120x160, Roger?  I maintain it that way=20
locally for the VX4500.

Peter Dufault
HD Associates, Inc.

Re: [Bitpim-devel] Patch for VX4500 calendar

[Roger B. <ro...@ro...>]

Peter Dufault wrote:
> > I've attached a patch that let's you at least read back the calendar
> > from your phone.  

Comitted.

> > Given my great abilities in python I might not add them that soon,
> > either.

My intention for the 0.8 releases is to concentrate on the calendar.
For 0.7 it is to get the phonebook and phonebook importing working
well.

> > 1. What are the "changeserial" and "snoozedelay" fields for the vx4400?

Changeserial is wrong.  The field is something else, I think the UI 
for repeat events or something similar.  I never quite got around
to fixing it.

snoozedelay is an internal detail on the phone.  As far as I can tell,
the phone runs a task that reads the calendar at the beginning of every
minute.

So say the event is set for 1pm, and the alarm is set for 1 hour.
The alarm will go off at 1pm - 1 hour = midday.  If the user then
presses snooze while the alarm is going off, snoozedelay becomes
non-zero.  I forget how long the snooze is, but lets assume 5 minutes.
So the alarm then goes off at 1pm - 1 hour + snoozedelay = 12:05.
If you press snooze again, then snoozedelay is set to 10 minutes.
It is all nice and simple, and works correctly even if the
phone is rebooted (assuming the reboot isn't at the top of a
minute :-)

> > 2. I've attached some logs I got from the phone.  

After my commit, the log should now should your protocol decoding which
makes it a lot easier to look at.

Roger

[Bitpim-devel] How hard is cell phone syncing?

[Roger B. <ro...@ro...>]

(I spotted even more grammar mistakes in previous mail - please indulge
me as I was very tired at the time :-)

Anyway, I didn't mention what is actually hard or different about cell
phone syncing.  There are two things - losing information and information
degradation.

Losing information or meaning
=============================

The PIM you sync with needs to be able to contain a superset of all
information otherwise the sync will lose information.  For example, if
it doesn't know anything about speed dials, then syncing with a PIM
will tend to lose your speed dials.  This leads to people being reluctant
to sync and the phone becoming an island of accurate information.

It can get quite a bit more complicated.  For example the LG phones
store 5 phone numbers and the order matters.  Many PIMs don't care
about the order of phone numbers.  That means that sending the numbers
back out from the PIM can scramble the numbers in the phone.

Sometimes you have to do mappings and be very careful with them.  For
example the Palm Desktop has a phone number type of 'main' and the
Sanyo phones have a phone number type of 'data'.  No other PIM to my
knowledge has the 'main' number type (including BitPim) and BitPim
appears to be the only one that has 'data'.  The syncs often translate
the information into another type - for example they may take the
'main' number from Palm, and turn it into 'office' and store it that
way.  Of course when you sync back with Palm, they have lost the information
that the number was actually type 'main', and write it back into the
'office' field in Palm.  There may already be a different 'office'
field, so they end up putting it in 'office2'.  Before you know it,
you will find each entry has several phone numbers duplicated, and
every time you sync it gets worse.  (This actually happened with me
using TrueSync several years ago).

Sometimes they don't provide enough granularity.  On the LG phones you
can have two different ringtones for a person - one for when they
call and one for when they send a text message.  If the UI in the
PIM only allows setting one, then again information is lost.

The design of Chandler (and sometimes other PIMs) is to allow arbitrary
extra information to be stored alongside each entry.  This partly solves
the problem (for example you could store the extra phone number labelled
'data') but the user interface and other plugins are not going to know about
the extra information, its uses or its semantics.

And sometimes PIMs just have arbitrary limits - neither Outlook nor
Evolution will let you store more than two work phone numbers for someone.
Palm won't let you have more than a total of 5 phone numbers and email
addresses (though all five could be work phone numbers).

All this tells us is that many times the information stored and semantics
available in a PIM can be worse than the phone does, which makes people
reluctant to let their cell phone originated data near the PIMs.

Information degradation
=======================

This is the flip side of the coin.  The phone can be worse than the PIMs.
As a simple example, many of the PIMs can store names in UNICODE (ie
most characters used on the planet).  Well, our phones can do ASCII.
They may do some of the Spanish letters such as ñ but they certainly
won't do more complicated stuff (currency symbols, accented characters,
CJK symbols, punctuation).  So if the original record is "mañana",
then the phone may ultimately end up containing "mañana", "manana" or
"maana".

Why does this matter?  It matters when you are syncing.  The sync software
has to produce a list of changes that you made on the phone.  For example
it needs to work out that you changed a phone number or a name.  So
if the original data is "mañana" and the phone now says "maana", is that
because of information degradation, or because the user editted the value.

It matters in the phone number fields as well.  If one of the two 'home'
numbers has gone, is that because of how many 'home' numbers the phone
or other sync software can store, or because the user deleted one?

The pictureid associated with an entry will definitely be different.
It may be a low resolution version of the original, or it could be
changed.  Which?

The phone sometimes even has originals and degraded versions at the
same time.  The Sanyo phones and the Audiovox CDM8900 make low resolution
thumbnials of camera pictures.  Sync software has to figure out if
this happened and get the high resolution original from the phone
and figure out if the user made a change or if it is just the original
information the PIM stores.

Conclusion
==========

It is fairly obvious that it is impossible to do a perfect job.  Conversions
in either direction will end up losing information and meaning, and there
may also be information degradation that is impossible to differentiate
from the user editting information.

But just because it isn't possible to do a perfect job, doesn't mean we
can't try and get close.  That is what BitPim will be doing.  It is going
to require some smart thinking, smart testing, good feedback, and trial
and error.

Roger

[Bitpim-devel] Patch for VX4500 calendar

[Peter D. <du...@hd...>]

I've attached a patch that let's you at least read back the calendar 
from your phone.  You can't write them back yet, for at least two 
reasons:

1. I haven't added support for the new fields;
2. I haven't started reading/writing the voice memo files.

Given my great abilities in python I might not add them that soon, 
either.

A few questions:

1. What are the "changeserial" and "snoozedelay" fields for the vx4400?
2. I've attached some logs I got from the phone.  Do the additional 
fields that replace the end of the description make sense in terms of 
known file setups for cell phones?  At first glance it seems as if 
there is a two-byte boolean followed by a two-byte - 0x0f index, which 
seems weird.  In looking at the log look at the last few entries where 
I start adding additional events.

Peter

Re: [Bitpim-devel] Report on Chandler meeting

[Roger B. <ro...@ro...>]

Apologies for the grammatical and occasional punctuation errors.
Some copying and pasting removed all my smileys!.

This hideous sentence:

  The people are OSAF are amongst the most experienced, and 
  should ensure what implement in practise meets their what 
  they talk about in theory. 

Should read:

  The people are OSAF are amongst the most experienced, and 
  should ensure that what they implement in practise meets 
  what they talk about in theory. 

Roger

[Bitpim-devel] Report on Chandler meeting

[Roger B. <ro...@ro...>]

If you don't know what Chandler is, read the vision here:
http://www.osafoundation.org/Chandler_Compelling_Vision.htm
Remember that a vision is a target to aim at, not necessarily
current realities.

So I met with several folks from OSAF today, including Mitch Kapor.
It was very interesting for both sides, but also highlighted a
significant gulf between what BitPim does and what Chandler intends
to do, as well as the design philosophy behind both products.

Chandler is a beautiful edifice of a design.  It is this large
monolith whose internal design is capable of anything (in theory)
should someone write a plug-in (which they call parcels).  This
is a classic top down design.  They have not yet attempted to
write code to do with synchronization with anything else, although
they will be looking at Outlook real soon.  Chandler will
handle all sorts of things (such as email, contacts, groups,
acitivity logs).

BitPim is a bottom up design.  The low level stuff was written
first and then the higher level added on top.  Doing more things
in the future does require updates and tweaks to the internals
since they didn't have that high level design first (*).  BitPim
only handles cell phone related stuff.

This means that BitPim solves some problems today, and solves them
well, whereas Chandler solves many problems tomorrow (in theory)
and will solve them well tomorrow (in theory).

The people are OSAF are amongst the most experienced, and should
ensure what implement in practise meets their what they talk about
in theory.  They do also have to walk before they can run, and are 
not intending to deal with cellphones (certainly not to the level 
BitPim does) for the forseeable future. (Also note that software 
always takes longer to develop than you expect - Chandler is no 
exception.)

Mitch also believes that the cell phones will change (&).  The
current model is a cable, and some crappy protocol over it
with per phone model differences.  He expects phones to
have downloadable software that then does the synchronization
for you.  To a certain extent that is already possible with
BREW apps (Get It Now on Verizon) or J2ME.  Today in practise that
approach is also limited by other infrastructure issues
(like the carriers wanting lots of money, how much the BREW/J2ME
environment sees, what about calendars, having access to
your desktop through your firewall to sync with it etc).

I am very skeptical of that view, even though I wish it was
true.  It currently takes about a year to design a phone,
3 months to FCC certify it, another 6 to 9 months for a carrier
to offer it, plus about a year before customers buy it.
Consequently there is around a 3 year lead time from a cell
phone manufacturer getting a clue, and the average customer
possessing a device with that clue in it (!).

I have also observed that people seem to treat their cellphones
in two ways.  One group of people barely have any information
in it, and use the call history to call the numbers they usually
call.  The other group have up to date information in the
phone (and only in the phone).  They get paranoid about syncing
with desktops because when they do, the desktop apps lose information
(for example they may remove your speed dials, turn off picture
ids, re-order numbers etc).  Funnily enough, all the OSAF people
were in the latter category, with various amusing anecdotes.

There is also the possibility that the cell phone manufacturers
may try to make your cell phone the central repository of
information and all other sources subservient to it.

The good news is that software is not a zero sum game (in zero sum
games, someone has to lose for someone else to win).  All the various
bits of software and practises can "win" simultaneously and end users
can pick the best tools for the job at the time.

So what does this mean for BitPim?  There will be no changes in
BitPim - it will continue to work really well with as many features
of the supported cell phones as possible.  It will continue to
remain relevant for cell phones and not try to solve other problems.
(ie it will do one thing and do it well).

At some point in the future, the innards of Chandler as well as
external developer functionality will be sufficient to port some
functionality from BitPim to Chandler.  I expect it will be quite
a bit longer before Chandler could become the user interface for
BitPim.  (Both of these will be measured in years).

My own prediction is that our cell phones will continue to be
islands of accurate information, and that BitPim will be the
only piece of software that does a good job with all their
features for the phones it supports (#).

Both BitPim and Chandler are Open Source, and even appear to
be the same license.  That means that developers with time
can change the course of both.  I won't be committing my own time
to BitPim - Chandler interoperability for the forseeable future
(unless someone pays me and I am available to do so 

I also think Chandler is going to get bitten a few times
due to their top down design.  That is why I offered my
hard learned lessons to them, although they weren't yet
ready for the real low level details.(+)

I do think it is going to be an interesting next few years,
and I think end users will continue to benefit from choice.
Just remember to tell the vendors why you did or didn't buy
products, and remind them that ultimately they are there to
serve you.

Notes:

(*) That also turns out to be the Microsoft strategy.  Release
    a less capable product sooner, and do several versions 
    while those trying to make a perfect initial product find 
    it irrelevant by the time they release.  It also explains 
    why each version of Word had to have a new file format  It 
    also coincides with the open source maxim "release early
    and release often".  This strategy typically leads to
    far greater product takeup and closer matching of user
    needs 

(&) That is a typical software person's attitude.  They usually 
    don't understand that hardware companies consider software a 
    necessary evil and try to have as little of it as possible.  
    They generally see no gain through their software, and making 
    it better would just delay time to market and increase 
    development costs.

(!) Those are the figures for Verizon as far as I can tell.  I 
    don't think they are too different for other companies.

(#) The one curve ball is a network effect:
    http://en.wikipedia.org/wiki/Network_effect
    If people start demanding phones that sync with Chandler, that 
    could cause a rapid increase in the uptake of Chandler, and the 
    number of phones that do syncing with it.  I think Mitch has 
    some expectation of this happening. We already see a mild 
    version of it with some people not buying phones unless
    BitPim work with them.

(+) They also expect 3rd party developers to contribute a lot, and 
    that is how they expect the phone problem to be solved.  
    However the innards of Chandler will limit the exact information 
    that can be stored, what extra information means, and how other 
    plugins display them.  That has chicken and egg effect - 
    developers won't bother with something that isn't popular, and
    the people won't bother with something that doesn't have all 
    the features.

Bonus:

Here are some relevant articles by Joel Spolsky.  He talks about
software platforms, good software, chicken and egg issues,
design and architecture.  I certainly have my own thoughts about
the future, some of which I mention above.  These should help
you with yours.  Just remember that it is not a zero sum game
unless people have to pay money (as they won't be likely to
spend money twice to get the same thing).

Good Software Takes Ten Years. Get Used To it. 
http://www.joelonsoftware.com/articles/fog0000000017.html

Chickens and eggs, software platforms:
http://www.joelonsoftware.com/articles/fog0000000054.html

Building communities with software
http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html

How hard it is to make software platforms successful
http://www.joelonsoftware.com/articles/Platforms.html

Open source as a business strategy
http://www.joelonsoftware.com/articles/StrategyLetterV.html

You have to design before you implement
http://www.joelonsoftware.com/articles/NothingIsSimple.html

Don't Let Architecture Astronauts Scare You 
http://www.joelonsoftware.com/articles/fog0000000018.html

The best way to eliminate people's objections to switching to your 
product is to make it easy to switch back. 
http://www.joelonsoftware.com/articles/fog0000000052.html

And a bonus from Jakob Nielsen in mid-2000 about WAP.  It shows that
cell carriers didn't get it then, and still don't get it.  Do you
think they will suddenly get contact synchronisation?
http://www.useit.com/alertbox/20000709.html

Roger

Re: [Bitpim-devel] Fw: VX4600 support

[Roger B. <ro...@ro...>]

Dale wrote:
> Here is the new log file. Here is the order the show on the screen , 5
> phones number, 1 email, group,sound,memo field,wallpaper,not secret,url

I have committed code that decodes your example entry, but you are going
to have to do some more experimentation.  Basically look in the protocol
log, change one thing, and see if it decodes the change correctly.

You should also make sure that various fields are the maximum length
possible. 

Do not try and write back to your phonebook yet (I would expect 
exceptions anyway).

Incidentally, are you in Canada?  I think the way your phone is
behaving is what models with Java (J2ME) do.  If that is the
case then the VX4600 you have and the one Verizon has in the
US will be different.

Roger

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

[Roger B. <ro...@ro...>]

Stephen Wood wrote:
> 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.

> 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.

> 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.
 
> 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.

> 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.

> 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?

> 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

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

[Stephen W. <sa...@ge...>]

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

Re: [Bitpim-devel] LGVX4500,6000 wallpaper observations

[Peter D. <du...@hd...>]

On May 12, 2004, at 6:55 PM, Roger Binns wrote:

> That all suggests that the index files may have changed format etc.
> The only way to check is to clear them out, and get content via
> the phone (eg via downloads etc).
>

I'm not sure what you mean by this.  Do you mean clear out the phone, 
down-load wallpaper via something other than BitPim, and then do 
uploads of the stuff downloaded and look at the logs to 
reverse-engineer any changes?  If so I'll leave that to someone else as 
I only use BitPim.

Peter

Peter Dufault
HD Associates, Inc.

Re: [Bitpim-devel] LGVX4500,6000 wallpaper observations

[Roger B. <ro...@ro...>]

Peter Dufault wrote:
> Then I started to look at the images on the phone.  Sometimes I'd get a
> white background instead of an image, and then the phone would crash
> (turn itself off).

The "white image" is what happens on the VX6000 if feeding it jpg.
(The preview is fine, but setting the image just gives white).

> directly to them I can reference them, but there is something screwy
> about our "metadata" for the images.

That all suggests that the index files may have changed format etc.
The only way to check is to clear them out, and get content via
the phone (eg via downloads etc).

> 1 The screen resolution on the VX4500/VX6000 can probably be changed
> from 120x131 to 120x160.

I have the VX6000 and the 120x131 setting is fine.

> 3 I've only managed to get BitPim to crash once in the manner reported
> this morning in spite of a lot of testing.

In reality there is nothing we can do about the Mac crashes unless
someone can actually establish which line of code is triggering the
problem.  There isn't any issue with the BitPim code, just that 
wxWindows 2.4 isn't that good for Mac.  The next release 2.5 is a lot
better for Mac support and we will be moving to it.

Roger

[Bitpim-devel] LGVX4500,6000 wallpaper observations

[Peter D. <du...@hd...>]

(OSX 10.3.3, LGVX4500, latest BitPim cvs'd at 5:30PM EDT, Verizon 
Wireless cable)

After discovering that I managed to get the same crash as reported on 
the bitpim-user list this AM, I decided to download and upload a bunch 
of wallpapers.

So I downloaded and uploaded 16 of them, twice, without any problem.

Then I started to look at the images on the phone.  Sometimes I'd get a 
white background instead of an image, and then the phone would crash 
(turn itself off).  It would always start up again fine.  The weird 
thing is it wasn't always the same image, though if I started at the 
first and moved forward it would always crash at the ninth.

I had noticed earlier that websites with wallpaper for the VX4500 use a 
120x160 resolution, and not the 120x131 resolution set in bitpim.  I 
changed the resolution to 120x160 and downloaded an image and saw that 
it worked fine on the VX4500.

Next I downloaded the images at 120x160, thinking maybe that was the 
problem.  I found that the images worked OK but the phone still hung 
up.  A little investigation shows that if I go directly to an image I 
can see it, but if I start with an image and "left and right arrow" 
through them I'll eventually get the white screen and then the phone is 
toast.  In other words, the images are sort of there, and if I go 
directly to them I can reference them, but there is something screwy 
about our "metadata" for the images.

So, three observations:

1 The screen resolution on the VX4500/VX6000 can probably be changed 
from 120x131 to 120x160.

2 There is still screwiness about wallpaper on the VX4500.

3 I've only managed to get BitPim to crash once in the manner reported 
this morning in spite of a lot of testing.

Peter

Peter Dufault
HD Associates, Inc.

RE: [Bitpim-devel] Fw: VX4600 support

[Dale <dri...@te...>]

Here is the new log file. Here is the order the show on the screen , 5
phones number, 1 email, group,sound,memo field,wallpaper,not secret,url

RE: [Bitpim-devel] Fw: VX4600 support

[Dale <dri...@te...>]

Ok will do, I can only have one email address. 

-----Original Message-----
From: bit...@li...
[mailto:bit...@li...] On Behalf Of Roger Binns
Sent: Wednesday, May 12, 2004 12:35 PM
To: bit...@li...
Subject: Re: [Bitpim-devel] Fw: VX4600 support

Dale wrote:
> Here is the file, I hope this works

Yes.  They have frigged with the email addresses.  How many can you have?

Also please create as many email addresses as possible for that first entry,
and make each one as long as possible.  Post the protocol log again (you
will still get the exception - ignore it).  I actually only need the very
last packet - the one containing <#! p_lgvx4500.pbreadentryresponse !#>

Roger


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software Learn developer
strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher
performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bitpim-devel mailing list
Bit...@li...
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

Re: [Bitpim-devel] Fw: VX4600 support

[Roger B. <ro...@ro...>]

Dale wrote:
> Here is the file, I hope this works

Yes.  They have frigged with the email addresses.  How many can you have?

Also please create as many email addresses as possible for that first 
entry, and make each one as long as possible.  Post the protocol log
again (you will still get the exception - ignore it).  I actually only
need the very last packet - the one containing
<#! p_lgvx4500.pbreadentryresponse !#>

Roger

RE: [Bitpim-devel] Fw: VX4600 support

[Dale <dri...@te...>]

Here is the file, I hope this works
 

-----Original Message-----
From: bit...@li...
[mailto:bit...@li...] On Behalf Of Roger Binns
Sent: Wednesday, May 12, 2004 10:42 AM
To: bit...@li...
Subject: Re: [Bitpim-devel] Fw: VX4600 support

Dale wrote:
> Hi Roger, I started looking into the phone book stuff. I did what you 
> said and looking at the protocal logging I get an error after reading 
> the first entry in the phone book.The error is 'pbentry' object has no 
> attribute '_pbentry__field_serial2'

Please post the protocol log here.  Make sure it is an attachment to the
email message, not part of the body.

Roger

Re: [Bitpim-devel] Fw: VX4600 support

[Roger B. <ro...@ro...>]

Dale wrote:
> What is the best way to get the protocal log as an attachment, just
> highlight it and save it to text? Or is there something inside the protocal
> log that can save the log file.

You have to copy and paste it into notepad or something similar.

Roger

RE: [Bitpim-devel] Fw: VX4600 support

[Dale <dri...@te...>]

What is the best way to get the protocal log as an attachment, just
highlight it and save it to text? Or is there something inside the protocal
log that can save the log file. 

-----Original Message-----
From: bit...@li...
[mailto:bit...@li...] On Behalf Of Roger Binns
Sent: Wednesday, May 12, 2004 10:42 AM
To: bit...@li...
Subject: Re: [Bitpim-devel] Fw: VX4600 support

Dale wrote:
> Hi Roger, I started looking into the phone book stuff. I did what you 
> said and looking at the protocal logging I get an error after reading 
> the first entry in the phone book.The error is 'pbentry' object has no 
> attribute '_pbentry__field_serial2'

Please post the protocol log here.  Make sure it is an attachment to the
email message, not part of the body.

Roger


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software Learn developer
strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher
performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Bitpim-devel mailing list
Bit...@li...
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

Re: [Bitpim-devel] ...Mac other error....

[Roger B. <ro...@ro...>]

Steven Palm wrote:
> Or I get this:  (I may be going blind, but I can't determine what port
> it's using here either, should I be able to?)

Yes, it is in the Log pane.

For some reason your phone is misbehaving.  The VX6000 diagnostics
interface should always be in diagnostics mode, and you shouldn't
have seen the usb error or this one.

Anyway the fix is to reboot your phone, but please don't do that
yet.  Add this method to _usbdevicewrapper:

    def inWaiting(self):
        return 0

I think you will still end up with a USB exception if no data comes
back.

Roger

Re: [Bitpim-devel] Fw: VX4600 support

[Roger B. <ro...@ro...>]

Dale wrote:
> Hi Roger, I started looking into the phone book stuff. I did what you said
> and looking at the protocal logging I get an error after reading the first
> entry in the phone book.The error is 'pbentry' object has no attribute
> '_pbentry__field_serial2'

Please post the protocol log here.  Make sure it is an attachment to
the email message, not part of the body.

Roger