Discussion:
[BitPim-devel] Basic support for sktt imt2000
Yosef Meller
2005-02-19 22:41:38 UTC
Permalink
I've done the basics for SKTT IMT2000 (AKA "SK Music Slider" in Israel).
Currently it only supports reading names, categories and phone numbers,
but I wanted to get this in, since I'm starting a new semester now and
my work rate will go down.

An issue: I hard coded in a conversion from 'iso-8859-8' character set,
but I've put it in a variable that can take it's value from anywhere. I
think there should be a list box with encodings in the settings dialog.
Another option is to use the current locale for that. What do you think?
--
"Necessity may be the mother of invention but coffee is the fuel."
- seen on web.archive.org
Stephen Wood
2005-02-20 02:12:07 UTC
Permalink
On Sun, 20 Feb 2005 00:41:38 +0200, Yosef Meller
Post by Yosef Meller
I've done the basics for SKTT IMT2000 (AKA "SK Music Slider" in Israel).
Currently it only supports reading names, categories and phone numbers,
but I wanted to get this in, since I'm starting a new semester now and
my work rate will go down.
Yosef:

I'll be happy to check your code into the CVS, but first you need
to put your copyright on com_ and p_ files and license them with the
BitPim license (GPL with a special exception, see LICENSE) You can
repost the files with the copyright or email them to me.

Thanks, Stephen
Roger Binns
2005-02-20 03:14:10 UTC
Permalink
Post by Stephen Wood
I'll be happy to check your code into the CVS, but first you need
to put your copyright on com_ and p_ files and license them with the
BitPim license (GPL with a special exception, see LICENSE) You can
repost the files with the copyright or email them to me.
Also remember to include a note for the change history file and
decide how you want help pages done (one set of pages for the
model family, one set of pages per model etc).

Roger
Yosef Meller
2005-02-20 19:33:33 UTC
Permalink
Post by Roger Binns
Post by Stephen Wood
I'll be happy to check your code into the CVS, but first you need
to put your copyright on com_ and p_ files and license them with the
BitPim license (GPL with a special exception, see LICENSE) You can
repost the files with the copyright or email them to me.
Also remember to include a note for the change history file and
decide how you want help pages done (one set of pages for the
model family, one set of pages per model etc).
And that would be help/versionhistory.htd, right? OK, I'll do this
tommorow, I believe.
--
Keep on rocking in a free world!
Yosef Meller
2005-02-21 17:55:18 UTC
Permalink
Post by Roger Binns
Post by Stephen Wood
I'll be happy to check your code into the CVS, but first you need
to put your copyright on com_ and p_ files and license them with the
BitPim license (GPL with a special exception, see LICENSE) You can
repost the files with the copyright or email them to me.
Also remember to include a note for the change history file and
decide how you want help pages done (one set of pages for the
model family, one set of pages per model etc).
The help pages should be a set for the model family, Pelephone has a few
models that are not that different AFAICT.

I didn't get exactly how much of the help files is auto-generated and
how much I need to write myself, I saw some scripts in help/ but didn't
have time to read through.

Do I need to directly edit versionhistory.htd and add htd files for my
phone?
--
"No, I do not contain myself,"
were the final words from the set of self-excluding sets. :-)
Stephen Wood
2005-02-21 17:50:50 UTC
Permalink
On Mon, 21 Feb 2005 19:55:18 +0200, Yosef Meller
Post by Yosef Meller
The help pages should be a set for the model family, Pelephone has a few
models that are not that different AFAICT.
I would suggest, that until more Pelephonephones are added, or more
features are added to this driver, that just a single help page is
sufficient.
Post by Yosef Meller
I didn't get exactly how much of the help files is auto-generated and
how much I need to write myself, I saw some scripts in help/ but didn't
have time to read through.
Roger has to generate the initial files, which are essentially blank.
After those are created, any developer can add your text in.
Post by Yosef Meller
Do I need to directly edit versionhistory.htd and add htd files for my
phone?
You can just post a one or two sentence blurb for the version history
and whatever text you want for the help file(s) and someone will check
it into the CVS.

What are your further plans with support for this phone? I am
guessing that writing to the phonebook will provide difficult unless
you can reverse engineer the phonebook protocol. (As discussed here
recently, successful support for phonebook writing is usually done
with a phonebook protocol rather than writing to the filesystem
directly.). If you can figure out how to upload music to the phone
that would probably be a valuable thing as I presume that one incurs
data charges to transfer music to the phone over the air.

Stephen
Yosef Meller
2005-02-21 19:11:39 UTC
Permalink
Post by Stephen Wood
On Mon, 21 Feb 2005 19:55:18 +0200, Yosef Meller
Post by Yosef Meller
The help pages should be a set for the model family, Pelephone has a few
models that are not that different AFAICT.
I would suggest, that until more Pelephonephones are added, or more
features are added to this driver, that just a single help page is
sufficient.
Agreed.
Post by Stephen Wood
Post by Yosef Meller
I didn't get exactly how much of the help files is auto-generated and
how much I need to write myself, I saw some scripts in help/ but didn't
have time to read through.
Roger has to generate the initial files, which are essentially blank.
After those are created, any developer can add your text in.
Post by Yosef Meller
Do I need to directly edit versionhistory.htd and add htd files for my
phone?
You can just post a one or two sentence blurb for the version history
and whatever text you want for the help file(s) and someone will check
it into the CVS.
So my message to the world would be: "SK6100: added basic read-only
access to the phone book".
Post by Stephen Wood
What are your further plans with support for this phone? I am
guessing that writing to the phonebook will provide difficult unless
you can reverse engineer the phonebook protocol. (As discussed here
recently, successful support for phonebook writing is usually done
with a phonebook protocol rather than writing to the filesystem
directly.). If you can figure out how to upload music to the phone
that would probably be a valuable thing as I presume that one incurs
data charges to transfer music to the phone over the air.
My immediate plans are to write a better packet description for reading
the phonebook (I have some unknown fields that I kno are just part of
the previous field, but I need to test that). Then I'll want to see what
other info I can extract from the phone. My first priority is reading -
for backup purposes. I don't buy ringtones anyway, so writing into the
phone will wait a bit. I intend to announce this basic version on the
local linux group so maybe someone who has this on a higher priority
would jump on the bandwagon.
--
"Necessity may be the mother of invention but coffee is the fuel."
- seen on web.archive.org
Yosef Meller
2005-02-20 19:31:04 UTC
Permalink
Post by Stephen Wood
On Sun, 20 Feb 2005 00:41:38 +0200, Yosef Meller
Post by Yosef Meller
I've done the basics for SKTT IMT2000 (AKA "SK Music Slider" in Israel).
Currently it only supports reading names, categories and phone numbers,
but I wanted to get this in, since I'm starting a new semester now and
my work rate will go down.
I'll be happy to check your code into the CVS, but first you need
to put your copyright on com_ and p_ files and license them with the
BitPim license (GPL with a special exception, see LICENSE) You can
repost the files with the copyright or email them to me.
Thanks, Stephen
There we go. I hope I got it right this time.
--
"Necessity may be the mother of invention but coffee is the fuel."
- seen on web.archive.org
Stephen Wood
2005-02-20 23:10:01 UTC
Permalink
Yosef:

I checked your code into the CVS. I took the liberty of using sk6100
to make the filename, since that seems to be the model number.
(IMT2000 seems to be standard rather than model designation). I also
changed the indentation leve from 8 spaces to 4 spaces to be like
other BitPim files.

I also added the SK6100 to the phone list in guiwidgets, but commented
it out. Please test that this all works with the changes I made, and
I'll update guiwidgets again.

What carrier(s) is this phone used on?

Stephen

On Sun, 20 Feb 2005 21:31:04 +0200, Yosef Meller
Post by Yosef Meller
There we go. I hope I got it right this time.
Yosef Meller
2005-02-21 17:34:52 UTC
Permalink
Post by Stephen Wood
I checked your code into the CVS. I took the liberty of using sk6100
to make the filename, since that seems to be the model number.
(IMT2000 seems to be standard rather than model designation). I also
changed the indentation leve from 8 spaces to 4 spaces to be like
other BitPim files.
I also added the SK6100 to the phone list in guiwidgets, but commented
it out. Please test that this all works with the changes I made, and
I'll update guiwidgets again.
It works all right.
Post by Stephen Wood
What carrier(s) is this phone used on?
Pelephone
--
"Necessity may be the mother of invention but coffee is the fuel."
- seen on web.archive.org
Roger Binns
2005-02-20 03:21:12 UTC
Permalink
Post by Yosef Meller
An issue: I hard coded in a conversion from 'iso-8859-8' character set,
but I've put it in a variable that can take it's value from anywhere. I
think there should be a list box with encodings in the settings dialog.
Another option is to use the current locale for that. What do you think?
I still don't understand the relevance. The encoding is a property of the
phone. I haven't come across any that let you change their encoding.
The phone model specific code should detect and use the phone encoding.
Since all phones are fixed, that isn't particularly hard nor does it need
to be exposed to the user.

The actual data in BitPim is stored in Unicode. Consequently the phone
model specific code must convert into and out of unicode. This is something
that isn't user visible.

Something I would like is a convertor from unicode that can munge characters
correctly such as changing an ể with an accent into an 'e'. The main Python
convertors just drop the character completely.

Roger
Yosef Meller
2005-02-20 19:43:28 UTC
Permalink
An issue: I hard coded in a conversion from 'iso-8859-8' character=
set,
but I've put it in a variable that can take it's value from anywhe=
re. I
think there should be a list box with encodings in the settings di=
alog.
Another option is to use the current locale for that. What do you =
think?
=20
=20
I still don't understand the relevance. The encoding is a property=
of the
phone. I haven't come across any that let you change their encodin=
g.
The phone model specific code should detect and use the phone encod=
ing.
Since all phones are fixed, that isn't particularly hard nor does i=
t need
to be exposed to the user.
What if a phone is used by a carrier in Israel differently then in US=
A?=20
The encoding would probably still be 8-bit, but decoding from latin1 =
to=20
unicode is not the same as decoding from iso-8859-8. So how can we te=
ll?=20
Is it something I can extract from the phone? I browsed through the=
=20
filesystem and couldn't find a clue.
The actual data in BitPim is stored in Unicode. Consequently the p=
hone
model specific code must convert into and out of unicode. This is=
=20
something
that isn't user visible.
I understand that.
Something I would like is a convertor from unicode that can munge=
=20
characters
correctly such as changing an =E1=BB=83 with an accent into an 'e'.=
The main=20
Python
convertors just drop the character completely.
This would have to do with character classes. I think perl's Encode=
=20
module can handle those, but I don't know about python.
--=20
"No, I do not contain myself,"
were the final words from the set of self-excluding sets. :-)
Stephen Wood
2005-02-20 19:03:18 UTC
Permalink
Very often, when a phone is available on different carries, the
firmware and protocol is different. For example, the Sanyo 8100 on
Sprint (US), and Bell (Canada) use similar but different protocols for
reading the phonebook.

So we can just specify that this driver is specific for your phone and
carrier (Pelephone?). If someone wants to develope a driver for the
phone in a different country, they can deal deciding if and how to
reuse your code.

Stephen

On Sun, 20 Feb 2005 21:43:28 +0200, Yosef Meller
What if a phone is used by a carrier in Israel differently then in USA?
The encoding would probably still be 8-bit, but decoding from latin1 to
unicode is not the same as decoding from iso-8859-8. So how can we tell?
Is it something I can extract from the phone? I browsed through the
filesystem and couldn't find a clue.
Roger Binns
2005-02-21 06:39:11 UTC
Permalink
What if a phone is used by a carrier in Israel differently then in USA?
The encoding would probably still be 8-bit, but decoding from latin1 to
unicode is not the same as decoding from iso-8859-8. So how can we tell?
Is it something I can extract from the phone? I browsed through the
filesystem and couldn't find a clue.
We'll deal with this the first time it ever becomes an issue. Based on
past and current experience, it never will be an issue. The model numbers
and carriers end up being different.

I don't believe the character set is present in the filesystem anywhere.
I would expect that the handset manufacturer sets it as a #define when
they build the firmware.

Roger
Yosef Meller
2005-02-21 17:38:15 UTC
Permalink
Post by Roger Binns
Post by Yosef Meller
What if a phone is used by a carrier in Israel differently then in
USA? The encoding would probably still be 8-bit, but decoding from
latin1 to unicode is not the same as decoding from iso-8859-8. So how
can we tell? Is it something I can extract from the phone? I browsed
through the filesystem and couldn't find a clue.
We'll deal with this the first time it ever becomes an issue. Based on
past and current experience, it never will be an issue. The model numbers
and carriers end up being different.
I accept your and Stephen's points on that issue. Quite a relief
actually - saves me the work of doing what I asked for :-)
--
"It doesn't just rock - it plays German Heavy Metal!"
- from some forum I can't remmember now (probably spreadfirefox.com)
Loading...