[Bitpim-devel] Re: [bitpim-cvs-checkins] bitpim bpcalendar.py,1.6, 1.7

[d***@netzero.com]

Will attempt to do so. Not being familiar with the process of this project, I figured all I'd have to do was to put the code out. I guess I was overly optimistic. :-)

Fix bug 1062904
+ self.setdirty(False)

That was easy :-) You should also close the tracker item.
If your changes are user visible, or because the issue mattered
enough to a user that they reported it, then also edit
help/versionhistory.htd

Roger


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Bitpim-devel mailing list
Bitpim-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitpim-devel


________________________________________________________________
Look for special offers on
NetZero Platinum & NetZero HiSpeed
Visit Best Buy, RadioShack or Kmart Today.

[Roger Binns]

Post by d***@netzero.com
Not being familiar with the process of this project, I figured
all I'd have to do was to put the code out. I guess I was overly
optimistic. :-)

There really isn't that much to it :-)

- There are builds every two weeks assuming sufficient changes
have happened. Don't put in risky changes around that time!

- User visible changes and changes of non-trivial scope should
be mentioned in help/versionhistory.htd - it is effectively
the changelog.

- Feel free to edit the online help, but note that that the
source files have an extension of .htd and are somewhat
templated. DO NOT add/delete help files or images directly.
Email me and I will add them. This is due to the help file
project and editor which needs to know about new files the
right way. If you would like to view your updated help,
let me know and I will rebuild it all and update the website.
This always happens with every build as a minimum, and is
usually a little more often anyway.

- Most projects allow anyone to add tracker items, and then the
developers have to keep removing the dupes, answered in the
FAQ, and other crud. I decided that I had better things to
do with my time, so the goal was to ensure that the trackers
only have real issues, and no maintenance is needed.

If you click "Submit new" for any of the trackers, they all say
to go off and using the mailing lists etc. For ordinary users
who don't bother to follow those instructions, I move their
items to dump tracker category and close them.

As a developer I do recommend you use the trackers for the
purpose they were intended, which is real bugs and feature
requests.

- I strongly encourage being on the cvs-checkins mailing list.
Any replys you make come back to this list.

What we have, any commits etc can always be improved. If you
have any opinions of how big or little things including particular
commits can be improved, then speak up!

Roger

[Vic Heintz]

When I add a wallpaper via the BitPim GUI it receives no 'origin' key.
Whereas ringtones added this way are entered with an origin key of
"ringers". I presume this is controlled in a BitPim module common to
all phones since the behavior is the same no matter which phone model
is selected. Is this by design? It seems a bit inconsistent.

I ask this because having this origin unassigned creates a situation
that causes an exception in the A670 code (and I presume the A650
code). When such a wallpaper is sent to the phone and another wallpaper
send is done again without doing a get in between there is an invalid
comparison done on this non-existent key. I think I could possibly
patch this in my module but that may just hide a bigger problem.

Vic

[Roger Binns]

Post by Vic Heintz
When I add a wallpaper via the BitPim GUI it receives no 'origin' key.
Whereas ringtones added this way are entered with an origin key of
"ringers". I presume this is controlled in a BitPim module common to
all phones since the behavior is the same no matter which phone model
is selected. Is this by design? It seems a bit inconsistent.

The intention is that the 'origin' field should state where the
item came from. The user can also alter it to make it go somewhere
else. Items added directly in the UI should have no origin. For
most phones, the origin is mostly irrelevant. For some it is very
important. Using images, these are origins in the vx6000:

- builtins: These are the builtin items, which are selectable
by the user, but do not exist in the filesystem and cannot
be viewed, added or deleted.

- camera: BitPim will read items from the camera, but will ignore
writing back items with an origin of camera)

- images: This is the convention images directory/selection on the
phone

- mms: These are images sent using multimedia enabled SMS

- drm: These are copy protected images. The phone won't let
you send them anyone else.

When writing to the phone, all items with an origin of builtins and
camera are discarded. Then BitPim fills up each section with items
that have no origin while taking into account the limits of the phone
(each origin is limited by the phone to 20 or 30 entries).

(*) I don't remember if I actually do this, or if it is a good idea ...

Post by Vic Heintz
I ask this because having this origin unassigned creates a situation
that causes an exception in the A670 code (and I presume the A650
code). When such a wallpaper is sent to the phone and another wallpaper
send is done again without doing a get in between there is an invalid
comparison done on this non-existent key. I think I could possibly
patch this in my module but that may just hide a bigger problem.

What should be happening is that files coming from the phone should
always have an origin set as appropriate. Phones added via the UI
(and without user alteration) should have no origin. When writing
to the phone, you should endeavour to put items back in the origin
they have set. Then fill up on any items that have no origin set.
Note that items with an origin take priority of those that don't.
For example, if you have 10 slots for an origin of 'mms' and there
are 7 items coming in with an origin of 'mms' and 7 without any
origin, then you must take all of the 'mms' and 3 of the blank ones.
Note that the origin key will be missing if it is not set. The
easy way to deal with that in code is supplying a default of None

Post by Vic Heintz
d={ 'adict': 1}
print d.get('foo', None)

None

(BTW feel free to add this to the dev-docs directory I just made).

Roger