Michal Čihař - Blog Archives for English

Gammu stable release release by Marcin. This entry is here just to make automated checkers happy.

Today I tried for first time software for Sony-Ericsson K750i on Windows. The supplied Sony-Ericsson suite offers only sync, when I try to browse files, it says phone is not connected. Okay, usual manufacturer software quality, I didn't expect more :-).

Next I installed floAt's Mobile Agent. I read quite good reports about this software, so I had to see what competition does Wammu have on Windows :-).

After some troubles to configure phone connection, including some Windows restarts, I managed to download some data. I was very suprised that my contact names weren't correctly decoded (in vCard they're properly in UTF-8). Rest of support is on very simmilar level as in my Gammu branch, Wammu is still far behind, especially in GUI design.

After lot of coding, I can say that this phone is fully supported. All basic services should work in my Gammu branch and changes should be soon merged to official branch.

So what works?

• Phonebook with most of entries (no picture, voice commands and ringtones)
• Calendar
• Todo
• SMS
• Filesystem
• Various information, including detailed filesystem status and battery temperature ;-)

If you're using original Sony-Ericsson cable, try following configuration, and send me gammulog, if anything goes wrong:

[gammu]
connection = at
port = /dev/ttyACM0
logfile = gammulog
logformat = textall

Branch links are available at http://cihar.com/gammu/, you can directly download from http://dl.cihar.com/gammu/snapshot/.

Update: All needed changes had been merged in 1.09.00 release, so you don't have to care about development versions.

Today I hacked complete support for phonebook and calendar, so only big thing which is missing in my branch is todo support and support for some few AT*E commands, which I'd like to add. I expect to finish this tomorrow and push patches to Marcin.

Anyway as code is in quite good share right now, I'd welcome any testers, you can download snapshots and try at least downloading calendar and phonebook.

Yesterday, I finally managed to code something what could be taken as improvement for Sony-Ericsson phone owners. My Gammu branch can now read complete phonebook entries. The implementation is now far from being effective, but works good.

What needs to be improved is way for getting LUIDs, as reading complete phonebook just to get list of all LUIDs is big overhead and causes big slowdown when reading first entry. Parsing IrMC changelog might be a solution, but it would need removing of deleted entries, what is harder to implement. I will try to investigate this possibility later, as this is not required to be handled right now.

OpenUsability project has opened some projects to public. None of projects have been chosen as student work (I understand this, as I didn't put there much formal specification), but instead offered as open projects.

This is both good and bad news: Bad news because there is no sponsoring for the usability consultant, good news because the time frame is not restricted to January-April (they may start immediately ;-), and professionals can apply as well as students.

While looking at best way how to implement Sony-Ericsson support in Gammu, I found that I desperately need OBEX specification for that. After looking at IrDA website, where it has been designed. I was shocked by prices they request, so I start to look for other source.

Thanks to Jane, I found it! Well they should protect their content if they really want to charge some money...

Marcin, you want to know some problems I see in Gammu+. Okay, I finally found some time to look at it:

1. There is no design document, where can developer find how the code is organised and what is supposed to be API.
2. There is no definition of external API. Everything is mixed together in simmilar way as in Gammu.
3. I don't see reasong for passing pointers (and especially double pointers (eg. DebugInfo) instead of C++ references.
4. Why not using widestring constants instead of converting all using some function?
5. Why there are reimplemented lists in backup? All those GSM_Backup_*Entry IMHO can be replaced by list<GSM_*Entry>.
6. There is too much malloc used (you should need it very rarely in C++).
7. Too much reimplementation of standard C library (eg. wcscasecmp vs. UnicodeCaseCmp).

Okay, I'm tired of reading that code. There is no documentation, the code follows no design, etc. I know Gammu code, so I can a bit understand Gammu+ code, but I expected some more open project, with at least some documentation. If you want to attract developers, you need to document your code.

Gammu+ looks to me like rewrite of C code into C++ while fixing some of design flaws of the old one, but introducing new ones. I know that nobody is perfect, but when starting new project, you should have spent some time on designing it's internals, writing them down and maybe receive some comments from others.

I know nobody is perfect, I also made several projects with wrong design before (well, Wammu is one of the examples).

PS: I don't say that Gammu+ has no future. I only say that it is ulikely to attract more developers as lacks documentation in same way Gammu does. I tried to introduce some documentation it Gammu, but I alone can not document new code…

Ukolovnik 0.5 has been just released. New features:

• Fix upgrade error.
• Include Czech translation.

After playing with it a bit I found out: current Gammu support for this phone is not working at all. After some looking at sources I decided to do implementation same way as in Alcatel - overlay driver which will use AT functions if they can be used. If you're interested in testing, my code will grow in my arch repository (more information on http://cihar.com/gammu), I'm going to submit it to upstream once there will be completed some set of functionality.