bitpim-devel — For bitpim developers

Re: [Bitpim-devel] What is expected of getringtones/getwallpapers?

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

Stephen Wood wrote:
> What are mms and drm?

MMS is like SMS messages, but can also include media (the first M in
MMS) such as images and ringtones.  DRM on the VX6000 is a subdirectory
and is for copy protected MMS stuff - you can't forward, message or
email it to anyone else.

> The file extension on the movies is .mp4.  xine calls it MOV/MPEG-4.
> I'll see if I can grab a frame with ffmepg.

ffmpeg should be able to understand mpeg4, although there seem to
many variants of it.

Roger

Re: [Bitpim-devel] What is expected of getringtones/getwallpapers?

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

On Mon, 2004-04-19 at 17:37, Roger Binns wrote:

> I would appreciate it if you could update web/phonespec.html with
> various useful bits of information (such as this) as you find them
> out.
OK
> 
> Two things are added to the result dictionary.  One is an index
> describing each piece of media.  This is currently a name field 
> and an origin field (for example the VX6000 has images in 
> brew/shared, brew/shared/mms, brew/shared/mms/d, the camera and
> some builtin.  The origin fields are set to images, mms, drm
> camera and builtin respectively).
What are mms and drm?
> 
> Everything returned there ends up being selectable in the 
> phonebookentryeditor.  
At this point, I don't how to assign pictures or ringers to phone book
entries (except using the phone itself of course).

> 
> When writing out, images are sent to the origin they
> came from assuming the phone has it available.  If not
> they just get assigned to the first location with free
> space.  This means that you can trivially read everything
> from a VX6000 and dump them to a VX4400 without having
> to worry about the differening locations available.
For the Sanyo phones, I can read meadia from camera, internet downloads,
and cable uploads "directories".  But so far, I think I can only upload
to the cable uploads directory.

> > Some Sanyo phones can take short movies.  Can I return the movies in the
> > same structure as the wallpapers?
> 
> Sure.  The only current constraint is that it must be possible to
> display them as an image.  What format are they in? 
The file extension on the movies is .mp4.  xine calls it MOV/MPEG-4. 
I'll see if I can grab a frame with ffmepg.


				Stephen

Re: [Bitpim-devel] Idle handler bug

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

Steven Palm wrote:
> Just FYI, so it looks like the fix needs to be
> made just in the Linux wx implementation although making the routines
> re-entrant safe wouldn't hurt anybody. ;-)

I made all the OnIdle handlers re-entrant the other day.

Roger

Re: [Bitpim-devel] wxPython 2.5

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

Steven Palm wrote:
>   So, in his case it seemed as though changing to use tuples did not
> break 2.4... Did you try this in the instances you were looking at? 

Only a short piece of code uses space in sizers.  The other areas
I was looking at all involved drawing in DC's.  The 2.4 methods
are like this:

   DC.DrawBitmap(bmp, x, y)

In 2.5, you have to do one of the following:

   DC.DrawBitmap(bmp, (x,y) )

  or
  
   DC.DrawBitmapXY(bmp, x, y)

So there is no way to have the same line of code work with both,
which means versioned if statements all over the place.

> that *required* 2.5 is on a back back burner now, so I could care less
> when we move. ;-)

I would like to move for things like selectable HTML, toolbar icon
now available for GTK, CHM help on all platforms, zillions of bug 
fixes, and because Robin has hidden the 2.4 releases.

Roger

Re: [Bitpim-devel] wxPython 2.5

[Steven P. <n9...@n9...>]

On Apr 19, 2004, at 10:11 PM, Roger Binns wrote:
> However there are a large number of wx object methods where
> parameters have changed, typically from individual parameters
> into tuples.  There is no way to write the code so that it
> works on both wx 2.4 and 2.5 in one line.  It would have to
> look like this instead:
>
>    if wx.VERSION>=(2,5):
>          sizer.Add( (10,10), 0, wx.EXPAND)
>    else:
>          sizer.Add( 10, 10, 0, wx.EXPAND)

  ...Interesting. I did read through the migration docs, and even asked 
about it specifically on the mailing list. The answer I got was:

[QUOTED REPLY]
> For my own application, the only change I needed to make when moving 
> to 2.5 was to use tuples instead of two separate arguments when adding 
> empty space to a sizer, and that change was backwards compatible with 
> 2.4 so the updated code works on both versions without any 
> version-specific code. It's a few thousand lines of code so it's a 
> sizable app. Of course, YMMV, so I would recommend you read the 
> Migration Guide to see if any of the backwards-incompatible changes 
> are an issue for you first.

  So, in his case it seemed as though changing to use tuples did not 
break 2.4... Did you try this in the instances you were looking at? I 
haven't toyed with it at all, so I thought I'd ask first. No, Roger, 
I'm not assuming you're an idiot and didn't try it, I'm just asking. 
:-)

  All in all, I'm not in any hurry (any longer) to move to 2.5, and I'm 
working on setting up both sets of libraries/includes here with scripts 
to move me back and forth between them. The project I was working on 
that *required* 2.5 is on a back back burner now, so I could care less 
when we move. ;-)

  Just my $0.02.

[Bitpim-devel] wxPython 2.5

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

I just spent some quality time seeing how much effort is involved
in moving to wxPython 2.5.  Because we already use the new wx 
namespace, there was very little issue there.  There were also
some items manually imported from random bits of the wxPython
namespace as they weren't correctly exposed in the 2.4 wx
namespace.  Those are all trivial to deal with (took me about
3 minutes :-)

However there are a large number of wx object methods where
parameters have changed, typically from individual parameters
into tuples.  There is no way to write the code so that it
works on both wx 2.4 and 2.5 in one line.  It would have to
look like this instead:

   if wx.VERSION>=(2,5):
         sizer.Add( (10,10), 0, wx.EXPAND)
   else:
         sizer.Add( 10, 10, 0, wx.EXPAND)

Needless to say, it is a royal pain going through all the
code where these changes need to be made since it is a lot
of different methods.  I soon got bored.

My earlier instinct was to only support one version of wxPython
and that still remains the case.  There have been enough
bug reports about 2.5 that we will wait till the next release
and then do the switch.

Roger

Re: [Bitpim-devel] What is expected of getringtones/getwallpapers?

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

Stephen Wood wrote:
> What does BitPim expect the getwallpapers and getringtones routines to
> return?  I gather that it expects arrays of the actual contents of the
> files on the phone.  But what is the index of this array, the filename
> of the file on the phone?  That appears to be the case here:

I would appreciate it if you could update web/phonespec.html with
various useful bits of information (such as this) as you find them
out.

Two things are added to the result dictionary.  One is an index
describing each piece of media.  This is currently a name field 
and an origin field (for example the VX6000 has images in 
brew/shared, brew/shared/mms, brew/shared/mms/d, the camera and
some builtin.  The origin fields are set to images, mms, drm
camera and builtin respectively).

Everything returned there ends up being selectable in the 
phonebookentryeditor.  There is a same index attached to
this email.  Currently it is a dictionary with arbitrary
numbers as the keys.  (The numbers don't mean anything!
They are just a legacy of the earlier codebase where they
were the actual index numbers used on the VX4400.  Feel
free to update all the code to make it a list rather
than a dictionary. :-)

When writing out, images are sent to the origin they
came from assuming the phone has it available.  If not
they just get assigned to the first location with free
space.  This means that you can trivially read everything
from a VX6000 and dump them to a VX4400 without having
to worry about the differening locations available.

Note also that the current code doesn't write back to
the camera on the VX6000.  There are many ways to get
this wrong (eg knowing that you are trying to send back
an image you got from the camera but which has been
renamed in the camera UI).  I also saw little
utlity in it.

Anyway, that is what ends up in 'wallpaper-index'.  'wallpaper'
is a dictionary where each key is one of the names from
the index, and the value is binary data.

Back in the main BitPim code, it uses the names as the name
on the filesystem.  You could have mutliple entries in
the index with the same name but ...

> Some Sanyo phones can take short movies.  Can I return the movies in the
> same structure as the wallpapers?

Sure.  The only current constraint is that it must be possible to
display them as an image.  What format are they in?  The current
method I can see to display an image is to use ffmpeg to convert
to motion jpeg, and then rip the first frame out of the resulting
file.  For example, assuming the video is foo.movie,

  ffmpeg -i foo.movie foo.mjpg

The the first frame is gotten using the details on this page:

http://www.lokigames.com/development/download/smjpeg/SMJPEG.txt

If we want to get really fancy, the image can be replaced once
a second with a second into the the movie itself, so it somewhat
looks animated.

I am currently planning on using a custom version of Wine
and including it in the BitPim distribution.  (The last time
I checked, we only need the main binary, two shared library
and one dll totalling just under a meg compressed).  That
will allow just using the Windows version of ffmpeg,
and pvconv (which is only available on Windows).  Steven
may be able to pull something similar off with qemu, Wine
and some glue for the Mac.

> What would be suggested for handing duplicate filenames? 

There is logic behind the current scheme, mainly trying to
deal with having multiple models of phones, and doing the
right thing when moving stuff between them.  Having the same
name but different content would be somewhat confusing.
(This isn't necessarily the right solution, just what I
arbitrarily picked, and I am very open to changing it).

It also means that things like drag and drop or saving
out of the wallpaper/ringtone displays are simple.
If we allowed multiple files of the same name, then they
would have to stored in a hierarchy which would complicate
the saving or dragging.

> If one takes a
> picture with a Sanyo camera phone, then assigns it as a wallpaper to a
> phonebook entry, there will be two files on the phone with the same
> name.  The large file is the picture and the small file is the picture
> sized properly to be a wallpaper.

The VX6000 quite happily points at the original camera image.  It
never duplicates images in the same way.

What I would be inclined to do in your case is to give the camera
images a different name, or a unique prefix.  For example, if
the file is actually 'face.jpg' then call it that from wallpaper,
but from the camera call it '#camera_face.jpg' or something
similarly arbitrary.

Roger

[Bitpim-devel] What is expected of getringtones/getwallpapers?

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

What does BitPim expect the getwallpapers and getringtones routines to
return?  I gather that it expects arrays of the actual contents of the
files on the phone.  But what is the index of this array, the filename
of the file on the phone?  That appears to be the case here:

media[index[i]]=self.getfilecontents(location+"/"+index[i])

What about camera pictures such as here?
media[index[i]['name']]=self.getfilecontents("cam/pic%02d.jpg" % (i,))

Some Sanyo phones can take short movies.  Can I return the movies in the
same structure as the wallpapers?

What would be suggested for handing duplicate filenames?  If one takes a
picture with a Sanyo camera phone, then assigns it as a wallpaper to a
phonebook entry, there will be two files on the phone with the same
name.  The large file is the picture and the small file is the picture
sized properly to be a wallpaper.

					Stephen

Re: [Bitpim-devel] Offsets in media location tables

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

Stephen Wood wrote:
> In the LG phones, the ringtone and image location maps have offsets.
> Are these offsets arbitrarily chosen for convenience, or are they
> properties of the phone?

The index files look like this:

  2 UINT numentries
  *  LIST entries:
      2 UINT id
     50 STRING name  # different number of bytes on each model

The overal file is a fixed number of entries long (typically 20 or
30).  The id is what is used in the phonebook etc to refer to that
entry.   Entries with an id of -1/0xffff are unused.  This does
mean that the numentries field and the number of entries with
a valid id could differ.

When you delete something on the phone, it usually just changes that
entry to have an id of -1/0xffff.  Consequently you have "holes"
in the entries.

When writing a new index file out, the code always writes them
in id order.  No holes are left.  New entries are given the
lowest free id number.

Roger

[Bitpim-devel] Offsets in media location tables

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

Roger:

	In the LG phones, the ringtone and image location maps have offsets. 
Are these offsets arbitrarily chosen for convenience, or are they
properties of the phone?

				Stephen

Re: [Bitpim-devel] Audiovox 8900 Image Support

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

Dale Blount wrote:
> I've got some dumps of the simple binaries that the phone creates when
> an image is sent to the phone.  

The best thing to do is convert them to BitPim analyser format and
then email them to me.

The format looks like this:

10:41:40.843 A plain message
10:41:40.844 A message with some data
00000000 09 00 02 00 00 00 05 18 39 7d 40 18 3a 7d 13 10     ........9}@.:}..
00000010 01 00 64 64 01 00 00 4e 65 77 20 65 76 65 6e 74     ..dd...New event
00000020 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     x...............
00000030 02 00 00 00 11 09 d3 07                             ........
10:41:40.845 Another plain message

You can just use zeros for the time field, but you need the same
amount of punctuation and digits.  You can also leave out the
character dump on the right.

Roger

[Bitpim-devel] Audiovox 8900 Image Support

[Dale B. <bi...@da...>]

I've got some dumps of the simple binaries that the phone creates when
an image is sent to the phone.  I don't know python and don't really
have time to learn it currently, so I can make these available if anyone
would like to add better support for the phone into bitpim.  I Could
probably also grab these files for midi/mp3 ringers if needed.

Thanks, 
Dale

Re: [Bitpim-devel] Normal Ringtone handling

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

> When I go into the Phonebook entry editor for a person with the default
> ringer, I am not given the option to change the ringer. 

You need to click 'Add' at the top of the window and then work with
what appears.  The UI in the phonebookentryeditor is logically 
correct, but really needs some improvement.  I think the easiest
thing will be that if there are no fields present, it should
not be blank, but instead be text saying something like
"Click Add to place an entry here'.  I might even be able to 
remove the toolbar completely and have each field have its
own up/down/delete/add button.


> Should I be
> explicitly putting [{'ringtone': 'Normal', 'use': 'call'}] into the
> entry?

No.  In general try to avoid putting information into a record unless
it was explicitly set.  This makes merging information from multiple
sources a lot easier since we then know that if a field is present
it was actually a desired value.
 
> Does this happen with LG phones, or is the default ringer one of those
> listed in builtinringtones.

Entries with default ringers do not have anything listed if
you go into the phonebookentry editor.

Roger

[Bitpim-devel] Normal Ringtone handling

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

On the Sanyo phones, the default/normal ringtone, has, internal to the
phone, an id of zero.  Following other examples, I don't make ringtones
entries into the entry unless the ringtone id is greater than zero.

When I go into the Phonebook entry editor for a person with the default
ringer, I am not given the option to change the ringer.  Should I be
explicitly putting [{'ringtone': 'Normal', 'use': 'call'}] into the
entry?

Does this happen with LG phones, or is the default ringer one of those
listed in builtinringtones.

					Stephen

[Bitpim-devel] Idle handler bug

[Steven P. <n9...@n9...>]

On Apr 10, 2004, at 1:59 AM, Roger Binns wrote:
> Making this somewhat bitpim related, I also found a wierd issue
> with wxPython.  On Linux, wx.BeginBusyCursor calls all idle
> handlers.  If you call wx.BeginBusyCursor in an idle handler,
> you may get infinite recursion.

  I grabbed your sample code posted in the wxPython list and ran it on 
my Mac. It doesn't exhibit the problem you are seeing on Linux, the 
count is always 1 here. Just FYI, so it looks like the fix needs to be 
made just in the Linux wx implementation although making the routines 
re-entrant safe wouldn't hurt anybody. ;-)

Re: [Bitpim-devel] OT: ANN: dotamatic

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

[We should take this to dotamatic-devel]

Steven Palm wrote:
>   I built the CVS version on the Mac. It needs the same sort of magic
> that we put into BitPim to autosize windows, as they open at "no size"
> on the Mac (main and print preview that I tested anyway).

I have added you as a developer so feel free to fix the code 
directly :-)

>   I can provide you with the Mac build and the dotamatic.icns Mac format
> file if you'd like, but the sizing issues should be fixed first.

Yes please.  I fixed a few other bugs and the whole thing will now
be 0.2.

Making this somewhat bitpim related, I also found a wierd issue
with wxPython.  On Linux, wx.BeginBusyCursor calls all idle
handlers.  If you call wx.BeginBusyCursor in an idle handler,
you may get infinite recursion.

The important lesson there is to make sure that idle handlers
behave well when called in a re-entrant fashion.  It may also
explain some other wierdities that were happening.

A brief check of the BitPim code shows that several of
them could be tweaked a little to ensure that re-entrancy
is fine.

Roger

Re: [Bitpim-devel] OT: ANN: dotamatic

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

> > getting very frustrated with some XML issues in BitPim, I was sent a
> > link
> > to The Rasterbator: http://homokaasu.org/rasterbator/
> 
>   That is why you've been so quiet. :-)

Actually the XML is what was really annoying me.  I changed some
unrelated parts (as in fixed bugs) and suddenly it is all misbehaving.

I couldn't figure out a rational reason why (other than bugs in
Python itself).

Roger

Re: [Bitpim-devel] OT: ANN: dotamatic

[Steven P. <n9...@n9...>]

On Apr 9, 2004, at 12:35 AM, Roger Binns wrote:
> You may notice some similarities with the BitPim pages and help :-)

  I built the CVS version on the Mac. It needs the same sort of magic 
that we put into BitPim to autosize windows, as they open at "no size" 
on the Mac (main and print preview that I tested anyway).

  I can provide you with the Mac build and the dotamatic.icns Mac format 
file if you'd like, but the sizing issues should be fixed first.

Re: [Bitpim-devel] OT: ANN: dotamatic

[Steven P. <n9...@n9...>]

On Apr 9, 2004, at 12:35 AM, Roger Binns wrote:
> This is completely off-topic, but what the heck.  As I was sitting 
> there
> getting very frustrated with some XML issues in BitPim, I was sent a 
> link
> to The Rasterbator: http://homokaasu.org/rasterbator/

  That is why you've been so quiet. :-)

[Bitpim-devel] OT: ANN: dotamatic

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

This is completely off-topic, but what the heck.  As I was sitting there
getting very frustrated with some XML issues in BitPim, I was sent a link
to The Rasterbator: http://homokaasu.org/rasterbator/

It makes multi-page posters using large black dots based on your source
image.  Stick them on a wall and you have something resembling art.  
(It is about as close I get anyway :-)

I did a few and they worked well.  Then I started wondering about using
colour and drawing the dots in other ways.  36 hours later I am happy
to inflict dotamatic on you:

  http://dotamatic.sourceforge.net/

You may notice some similarities with the BitPim pages and help :-)
It is pronounced dot-a-matic.

Now back to figuring out why the XML library doesn't like some
simple stuff it generated itself.

Roger

[Bitpim-devel] CMX Studio

[Mike W. <mw...@co...>]

An eval copy of the CMX Studio is available on the following
Korean website, if anyone is interested:
http://www.mobilelab.co.kr/table/up/data_brew/cmxStudio_2_8_2_Lite_Tool.zip

Mike

[Bitpim-devel] BitFling update

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

BitFling now works between two machines, securely etc.
I still need to do some work to tidy up several loose ends.
This will allow developers to access someone elses phone
over the Internet.

It is also going to need some work on performance.
It currently reads files at 600 bytes/sec between
two machines on my LAN.  On the host directly 
accessing the phone, it is 10,000 bytes/sec.

Roger

Re: [Bitpim-devel] ringtones to new fileview

[Steven P. <n9...@n9...>]

On Apr 6, 2004, at 7:44 PM, Roger Binns wrote:
>>   But I will perservere. LoL. Eventually *something* has to give. 
>> <wink>
>
> Are you regretting touching the code yet :-?

  Well, in response to your "he who touched it last", I was recently 
thinking of... "But you started it!" :-)

> BTW what is the actual problem?  On both Linux and Windows, images drag
> perfectly into any part of the wallpaper view.  For the ringer view,
> they drag in perfectly as well, but there is a later exception while
> transmogrifying the name.

  Ugh! Well, it doesn't work on the Macintosh. This must be some 
platform issue, then. It wasn't working in ringer or wallpaper view...

  I found by changing the code in guiwidgets.py for the __init__ method 
of the FileView class putting in the following would allow it to work 
for the preview area and the icon view:

         self.droptarget=MyFileDropTarget(self)
         self.SetDropTarget(self.droptarget)
         self.icons.SetDropTarget(self.droptarget)
         self.preview.SetDropTarget(self.droptarget)

  However, it crashes something when you quit BitPim. :-(  Obviously 
this "magic bit" is doing something on the Mac, but it's not needed on 
the other platforms. <sigh>

  More digging. I'm about to check in some changes, test it on Windows 
and/or Linux and see how it fares there.

Re: [Bitpim-devel] ringtones to new fileview

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

>   But I will perservere. LoL. Eventually *something* has to give. <wink>

Are you regretting touching the code yet :-?

> At least finding out that registering the preview pane will finally get
> something to triggers shows that there is something to this train of
> thought...  as long as it's not the "crazy train". :-)

BTW what is the actual problem?  On both Linux and Windows, images drag
perfectly into any part of the wallpaper view.  For the ringer view,
they drag in perfectly as well, but there is a later exception while
transmogrifying the name.

Roger

Re: [Bitpim-devel] ringtones to new fileview

[Steven P. <n9...@n9...>]

On Apr 6, 2004, at 6:24 PM, Roger Binns wrote:
>>   So, it is something with not being attached to a proper wx control? 
>> I
>> dunno.... Just throwing this out to see if it rings any bells for you.
>
> There is a problem with the drag and drop and you have notebook panes.
> What I found was that it isn't necessarily the currently viewed pane
> that gets a drop message:

  Ah, but I was looking for ANY OnDropFiles() call, and none was 
happening. Very strange...

  I found that if I changed the registration call to not be the 
ringerview object, but rather it's preview pane, then a drop to that 
pane will work. I haven't found an object I can register for to get the 
left two panes, though... grid doesn't work, nor does tbsplitter or 
lrsplitter....

  I got this from a thread I found that suggested you may have to 
register every control in a view (sigh), although it wasn't conclusive:

  http://lists.wxwidgets.org/archive/wx-users/msg35311.html

  But I will perservere. LoL. Eventually *something* has to give. <wink> 
At least finding out that registering the preview pane will finally get 
something to triggers shows that there is something to this train of 
thought...  as long as it's not the "crazy train". :-)