Menu
▾
▴
bitpim-devel
|
From: Chris C. <cle...@oc...> - 2003-12-16 16:50:02
|
Hi, I just found this software yesterday, and am already excited. I just recently purchased two Sanyo 8100s (one for myself, one for my wife) and was disappointed to learn that the futuredial software only supported phonesync. Bah! Then this appeared! This software has amazing potential, so I look forward to working on it to get it to run more effectively not only on the 8100, but also on various platforms: Linux on my laptop, OS X on my wife's home machine, Win98 on my wife's work machine. I'd also like a way to sync/combine calendars, and fetch call logs in order to help in reconciling billing with clients. Warning, though: I know jack about python, so there will likely be some newbie questions regarding that. I am, however, no software novice, being proficient in C, C++, Java, perl, etc., and having designed and implemented many large-scale systems in the past & present. Thanks so much, Roger, for sharing this software with us! -cj -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2002 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<< |
|
From: Steven P. <n9...@n9...> - 2003-12-16 17:35:58
|
On Dec 16, 2003, at 10:49 AM, Chris Cleeland wrote: > This software has amazing potential, so I look forward to working on > it to > get it to run more effectively not only on the 8100, but also on > various > platforms: Linux on my laptop, OS X on my wife's home machine, Win98 > on my > wife's work machine. I'm the newly appointed Mac geek here. ;-) I'm working on getting some of the Mac specific things up to speed, such as USB cable support, comm port detection, application bundling, etc... Glad to have you on board with such enthusiasm, and looking forward to the future direction of the project. BTW: I just started using Python for this project as well, but it's pretty straight forward from everything I've run into so far. -. ----. -.-- - -.-- Steve Palm - n9...@n9... -. ----. -.-- - -.-- |
|
From: Jim <Ji...@ja...> - 2003-12-16 17:49:29
|
Python Rocks! Books I found useful when I first started: - Learning Python, Lutz/Ascher, OReilly, ISBN 1-56592-464-9 - Programming Python, Lutz, OReilly, ISBN 0-596-00085-5 - Text Processing in Python, Mertz, Addison-Wesley, ISBN 0-321-11254-7 - Python Cookbook, Printed and Online For wxPython see wxWindows doc set and the demo code. I too will be lending my skills to the furthering development of this wicked cool app. Roger's got quite the TO-DO list that I will be chipping away at. Jim West www.jameswest.com The box said Windows 95 or better, so I installed Linux. ---------- Original Message ----------- From: Steven Palm <n9...@n9...> To: bit...@li... Sent: Tue, 16 Dec 2003 11:35:54 -0600 Subject: Re: [Bitpim-devel] Another developer added to the fold > On Dec 16, 2003, at 10:49 AM, Chris Cleeland wrote: > > This software has amazing potential, so I look forward to working on > > it to > > get it to run more effectively not only on the 8100, but also on > > various > > platforms: Linux on my laptop, OS X on my wife's home machine, Win98 > > on my > > wife's work machine. > > I'm the newly appointed Mac geek here. ;-) > > I'm working on getting some of the Mac specific things up to speed, > such as USB cable support, comm port detection, application > bundling, etc... Glad to have you on board with such enthusiasm, and > looking forward to the future direction of the project. BTW: I just > started using Python for this project as well, but it's pretty > straight forward from everything I've run into so far. > > -. ----. -.-- - -.-- > Steve Palm - n9...@n9... > -. ----. -.-- - -.-- > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Bitpim-devel mailing list > Bit...@li... > https://lists.sourceforge.net/lists/listinfo/bitpim-devel ------- End of Original Message ------- |
|
From: Stephen W. <sa...@us...> - 2003-12-16 21:10:14
|
On Tue, 2003-12-16 at 11:49, Chris Cleeland wrote: ... > This software has amazing potential, so I look forward to working on it to > get it to run more effectively not only on the 8100, but also on various > platforms: Linux on my laptop, OS X on my wife's home machine, Win98 on my > wife's work machine. > > I'd also like a way to sync/combine calendars, and fetch call logs in order > to help in reconciling billing with clients. > ... Great! I added the support the Sanyo 8100. I actually only have a 4900, but it seems that the 4900 and 8100 are pretty similar (except for the camera of course!) Have you tried BitPim on your phone yet? Have you written to the phone? (I have a report of a 8100 owner reading the phonebook, but have not heard if anyone has tried writing to the phone. It should work.) I was going to work on improving general calendar support, but just havn't time. There is probably a lot of fun work there with syncing calendars and reading/writing iCalendar/vCalendar files. I can easily add fetching of the call logs into the BitPim calendar. Roger: Can you suggest a syntax for call history calendar entries so that the savecalendar routines for the various phones can know not to try to write these call logs into phone event calendars? Perhaps a calendar entry type flag with possible values like event call_alarm missed_call outgoing_call incoming_call message Steve |
|
From: Roger B. <ro...@ro...> - 2003-12-16 21:15:47
|
> I can easily add fetching of the call logs into the BitPim calendar. > Roger: Can you suggest a syntax for call history calendar entries so > that the savecalendar routines for the various phones can know not to > try to write these call logs into phone event calendars? Perhaps a > calendar entry type flag with possible values like > event > call_alarm > missed_call > outgoing_call > incoming_call > message I think I would rather keep the call history seperate from the actual calendar. (It too can also be displayed in a seperate calendar display, just not the main one). I don't think it would be useful for BitPim to write back out to the call history. One thing I was thinking of doing is injecting SMS messages into your email. The user can then use their standard email filtering to keep a log etc. The headers can even be suitably frigged so you can just hit reply etc. The same can be done for the call history. Any thoughts? Roger |
|
From: Stephen W. <sa...@us...> - 2003-12-16 21:52:14
|
On Tue, 2003-12-16 at 16:15, Roger Binns wrote: > I think I would rather keep the call history seperate from the > actual calendar. (It too can also be displayed in a seperate > calendar display, just not the main one). I don't think it > would be useful for BitPim to write back out to the call history. Yes, I don't see much value for writing a call history back to the phone. What about Call Alarms. On my phone, I have 15 slots for these. They are similar to events, except that they hold a phone number and a date/time. They are meant to remind you to call someone. I recently tentatively added reading and writing of these to the sanyo code. On writing, if a calendar entry description looks like a phone number, I send it to the Call Alarm list instead of the event list on the phone. > > One thing I was thinking of doing is injecting SMS messages > into your email. The user can then use their standard email > filtering to keep a log etc. The headers can even be suitably > frigged so you can just hit reply etc. It looks like Python has classes to handle various mailbox styles! > > The same can be done for the call history. I would like call history to be exportable from BitPim in whatever ways Calendar information is so that call histories can be imported in to other calendars. I'll add some code for reading the call history and SMS messages, but I won't try to do anything with the information yet. Steve |
|
From: Chris C. <cle...@oc...> - 2003-12-16 21:52:15
|
On Tue, 16 Dec 2003, Roger Binns wrote: > > I can easily add fetching of the call logs into the BitPim calendar. > > Roger: Can you suggest a syntax for call history calendar entries so > > that the savecalendar routines for the various phones can know not to > > try to write these call logs into phone event calendars? Perhaps a > > calendar entry type flag with possible values like > > event > > call_alarm > > missed_call > > outgoing_call > > incoming_call > > message > > I think I would rather keep the call history seperate from the > actual calendar. (It too can also be displayed in a seperate > calendar display, just not the main one). I don't think it > would be useful for BitPim to write back out to the call history. Writing out to call history probably isn't useful. However, from a user's perspective (not from an implementation perspective), I'd like to be able to view call log data from within the calendar view. > One thing I was thinking of doing is injecting SMS messages > into your email. The user can then use their standard email > filtering to keep a log etc. The headers can even be suitably > frigged so you can just hit reply etc. > > The same can be done for the call history. > > Any thoughts? Interesting, but requires extra services for Sprint phones (i.e., PCS Vision). While it's cool, it's not worth $10-15 /month more to me, so I'm looking to avoid using it. If data is available, I'd rather see it come through the serial port. -cj -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2002 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<< |
|
From: Roger B. <ro...@ro...> - 2003-12-16 22:03:48
|
> Interesting, but requires extra services for Sprint phones (i.e., PCS > Vision). While it's cool, it's not worth $10-15 /month more to me, so I'm > looking to avoid using it. If data is available, I'd rather see it come > through the serial port. It would come through the serial port. The general gist would be that if you told BitPim to import your SMS and/or call history, they would show up in your email client with appropriate date, to, from, subject and bodies. You can then do whatever filtering you want in your email client for putting stuff in folders. Roger |
|
From: Stephen W. <sa...@us...> - 2003-12-17 02:21:40
|
On Tue, 2003-12-16 at 17:03, Roger Binns wrote: > ... The general gist would be that > if you told BitPim to import your SMS and/or call history, they would > show up in your email client with appropriate date, to, from, subject > and bodies. You can then do whatever filtering you want in your email > client for putting stuff in folders. > I don't quite understand how we would really make call history fit in email. It would work if there was a database to translate nubmers into email addresses and an editor popped up that let you type in a subject and notes about each call, but that sounds like too much work for developers and users. Steve |
|
From: Chris C. <cle...@oc...> - 2003-12-17 02:27:49
|
On Tue, 16 Dec 2003, Stephen Wood wrote: > On Tue, 2003-12-16 at 17:03, Roger Binns wrote: > > > ... The general gist would be that > > if you told BitPim to import your SMS and/or call history, they would > > show up in your email client with appropriate date, to, from, subject > > and bodies. You can then do whatever filtering you want in your email > > client for putting stuff in folders. > > > I don't quite understand how we would really make call history fit in > email. It would work if there was a database to translate nubmers into > email addresses and an editor popped up that let you type in a subject > and notes about each call, but that sounds like too much work for > developers and users. Hi, Steve, If you want to branch CVS and commit some of the sanyo 8100 stuff you're working on so I can test it, let me know the branch tag and I'll pull it over and take a whack. In general, is there any kind of ChangeLog or anything on the project so that it's easy to track aggregate changes? -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2002 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<< |
|
From: Stephen W. <sa...@us...> - 2003-12-17 04:48:48
|
lopers and users. > > Hi, Steve, > > If you want to branch CVS and commit some of the sanyo 8100 stuff you're > working on so I can test it, let me know the branch tag and I'll pull it over > and take a whack. I don't need to branch anything. I'll add some code to read the call history and leave it disabled with an if statement or something. There are some data words included in the call history packets that I don't understand, so it would be good to have more eyes look at protocol logs. Make sure you try out your phone with the current CVS version. The Sanyo specific code has not had much testing beyond myself. > > In general, is there any kind of ChangeLog or anything on the project so that > it's easy to track aggregate changes? You can see changes on individual files with the viewcvs. The code for the Sanyo 4900/8100 is in the files com_sanyo4900.py, com_sanyo.py, and p_sanyo.p. |
|
From: Roger B. <ro...@ro...> - 2003-12-17 08:55:55
|
> You can see changes on individual files with the viewcvs. The code for
> the Sanyo 4900/8100 is in the files com_sanyo4900.py, com_sanyo.py, and
> p_sanyo.p.
BTW it is really easy to make a seperate module for the 8100 and share
all code, with any exceptions you want to make. I did it for the
VX6000 and VX4400. Here is how:
com_sanyo4900:
======
class Phone(...):
protocolclass=p_sanyo4900
desc="Sanyo 4900"
def calendar(self):
# whereever you need protocol objects, instantiate them like this
req=self.protocolclass.calendarentry()
======
p_sanyo8100:
======
%{
# This brings all objects from sanyo4900 into this namespace
from p_sanyo4900 import *
%}
# you can put any overrides here, eg if the calendarentry is
# a different size
PACKET calendarentry:
99 STRING description
======
com_sanyo8100:
======
class Phone(com_sanyo4900.Phone):
protocolclass=p_sanyo8100
desc="Sanyo 8100"
def __init__(self):
com_sanyo4900.Phone.__init__(self)
=======
The above will let you have seperate files for the phones, but share
all the code except whatever you decide to override. It also means
the user will see the correct phone model in any log messages.
Roger
|
|
From: Chris C. <cle...@oc...> - 2003-12-17 15:33:59
|
Okay, forgive the python ignorance...
On Wed, 17 Dec 2003, Roger Binns wrote:
> > You can see changes on individual files with the viewcvs. The code for
> > the Sanyo 4900/8100 is in the files com_sanyo4900.py, com_sanyo.py, and
> > p_sanyo.p.
>
> BTW it is really easy to make a seperate module for the 8100 and share
> all code, with any exceptions you want to make. I did it for the
> VX6000 and VX4400. Here is how:
>
> com_sanyo4900:
> ======
> class Phone(...):
>
> protocolclass=p_sanyo4900
> desc="Sanyo 4900"
>
> def calendar(self):
> # whereever you need protocol objects, instantiate them like this
> req=self.protocolclass.calendarentry()
> ======
>
> p_sanyo8100:
> ======
> %{
> # This brings all objects from sanyo4900 into this namespace
> from p_sanyo4900 import *
> %}
>
> # you can put any overrides here, eg if the calendarentry is
> # a different size
>
> PACKET calendarentry:
> 99 STRING description
> ======
At this point, there's only one protocol file for sanyo; are you suggesting
that it should be broken up, or just offering this as a suggestion?
> com_sanyo8100:
> ======
> class Phone(com_sanyo4900.Phone):
>
> protocolclass=p_sanyo8100
> desc="Sanyo 8100"
> def __init__(self):
> com_sanyo4900.Phone.__init__(self)
> =======
There's another class declared at the end of this file: class Profile. Does
that need to be inherited, too? Or, does it need to be broken out into a
separate class, or perhaps phonebook.py needs to be massaged to allow
individual phones to decorate a phone book entry?
--
Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
Principal Software Engineer, Object Computing, Inc., +1 314 579 0066
Support Me Supporting Cancer Survivors in Ride for the Roses 2002
>>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<<
|
|
From: Roger B. <ro...@ro...> - 2003-12-17 18:22:52
|
> At this point, there's only one protocol file for sanyo; are you suggesting > that it should be broken up, or just offering this as a suggestion? The email was mostly directed at Stephen who would know exactly what to do :-) Roger |
|
From: Roger B. <ro...@ro...> - 2003-12-17 08:44:02
|
> I don't quite understand how we would really make call history fit in > email. It would work if there was a database to translate nubmers into > email addresses You mean like the phonebook :-) Ok. here are some examples. Imagine your name is John Smith and number is 123 456 7890 For SMS it is easy. Incoming message: ====== From: 555...@vt... To: 123...@vt... Date: Jan 1 2003 Subject: Lunch # from SMS message body body body # from SMS message ====== An outgoing message would be the same except the contents of the From and To would be the other way round. Here is what an ordinary call would look like, assuming the number had been phone in your phonebook ====== From: 555555555 (Mary Brown) To: John Smith Date: Jan 1 2003, 10:43am Subject: Phone call: 25 minutes # could also be Missed Call, Outgoing call etc The same information in the body ====== The SMS case is very nice and easy but you already have things you can turn into email addresses, and you have something you can make subjects and bodies out of. The call history certainly is of less utility. If you already use a time tracking and annotation tool that hooks into your mailer, then having the call history in there too is great. If you don't then how do you track your email history? We will certainly have to be very careful exporting it to any calendar destination that is also a calendar source for BitPim. Roger |
|
From: Stephen W. <sa...@us...> - 2003-12-17 21:02:43
|
On Wed, 2003-12-17 at 03:44, Roger Binns wrote: > For SMS it is easy. Of course. ... > Here is what an ordinary call would look like, assuming the number > had been phone in your phonebook > > ====== > From: 555555555 (Mary Brown) > To: John Smith > Date: Jan 1 2003, 10:43am > Subject: Phone call: 25 minutes # could also be Missed Call, Outgoing call etc > > The same information in the body > ====== I still think call history makes more sense going into a/the calendar, but putting it in email has possibilities. If the phone number is in the phonebook and there is an email address for that name, the email address can be used as the "From". Also, if the phone number was a mobile, we could generate an SMS address. (Is there a SMS gateway where you can send to nu...@so... without having to do something different for different carriers). Steve |
|
From: Roger B. <ro...@ro...> - 2003-12-17 22:20:28
|
> (Is there a SMS gateway where > you can send to nu...@so... without having to do something > different for different carriers). Of course not! That would allow people to move easily amongst carriers :-) Roger |
|
From: Chris C. <cle...@oc...> - 2003-12-16 21:49:03
|
On Tue, 16 Dec 2003, Stephen Wood wrote: > I added the support the Sanyo 8100. I actually only have a 4900, but it > seems that the 4900 and 8100 are pretty similar (except for the camera > of course!) Have you tried BitPim on your phone yet? Yes. I have gotten exceptions, and am not yet versed enough in python or the structure of bitpim to understand what or why. Most particularly, it seems that it doesn't like to read into some of the nvm part of the > Have you written to the phone? (I have a report of a 8100 owner reading > the phonebook, but have not heard if anyone has tried writing to the phone. > It should work.) No, I haven't yet. > I was going to work on improving general calendar support, but just > havn't time. There is probably a lot of fun work there with syncing > calendars and reading/writing iCalendar/vCalendar files. Yes! That's what I want. Ultimately, I'd like for my wife and I to be able to sync our two calendars so that we can keep up with each others' schedules more easily. -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2002 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<< |
|
From: Steven P. <n9...@n9...> - 2003-12-16 22:05:24
|
On Dec 16, 2003, at 3:10 PM, Stephen Wood wrote: > I was going to work on improving general calendar support, but just > havn't time. There is probably a lot of fun work there with syncing > calendars and reading/writing iCalendar/vCalendar files. That would be cool to sync up with Apple's iCal application! :-) I'm going to take a look at a stub to integrate or at least import/export from Apple's system Address Book application. -. ----. -.-- - -.-- Steve Palm - n9...@n9... -. ----. -.-- - -.-- |
|
From: Chris C. <cle...@oc...> - 2003-12-16 22:11:00
|
On Tue, 16 Dec 2003, Steven Palm wrote: > > On Dec 16, 2003, at 3:10 PM, Stephen Wood wrote: > > I was going to work on improving general calendar support, but just > > havn't time. There is probably a lot of fun work there with syncing > > calendars and reading/writing iCalendar/vCalendar files. > > That would be cool to sync up with Apple's iCal application! :-) Yes! > I'm going to take a look at a stub to integrate or at least > import/export from Apple's system Address Book application. You would then rock :-) -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2002 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<< |
|
From: Stephen W. <sa...@ge...> - 2003-12-17 16:21:39
|
On Wed, 2003-12-17 at 10:26, Chris Cleeland wrote: > On Wed, 17 Dec 2003, Roger Binns wrote: > > > BTW it is really easy to make a seperate module for the 8100 and share > > all code, with any exceptions you want to make. I did it for the > > VX6000 and VX4400. Here is how: > > I will create a module for the 8100 in the next few days. While I believe that the 8100 interface is identical to the 4900 in those matters that have been put into BitPim, it is time to do it. And who knows, we may somehow figure out how to download camera pictures from the 8100, and since the 4900 doesn't have a camera, that's a difference. I will also make a module for the Sanyo SCP-5300 since I also believe that is similar. What I will do is move most of the code from com_sanyo4900.py into com_sanyo.py, and then create mostly empty com and protocol files for the three phones. Steve |
|
From: Chris C. <cle...@oc...> - 2003-12-17 16:52:39
|
On Wed, 17 Dec 2003, Stephen Wood wrote: > What I will do is move most of the code from com_sanyo4900.py into > com_sanyo.py, and then create mostly empty com and protocol files for > the three phones. That sounds like a good plan. What about the Profile class that's in there? Should there also be separate protocol specs for each phone, similar to what's being done for the communications? -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2002 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<< |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X