gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnokii + kaddressbook + encoding


From: Helge Deller
Subject: Re: gnokii + kaddressbook + encoding
Date: Mon, 31 May 2004 20:45:43 +0200
User-agent: KMail/1.6.52

On Monday 31 May 2004 20:15, Pawel Kot wrote:
> On Mon, 31 May 2004, Helge Deller wrote:
> 
> Hi Helge,
> 
> > Let's say, that data.phonebook_entry.name contains the name "Jürgen Öhm"
> > (with two umlauts) and the rest of the name field holds zeros, then
> > gnokii stores the name correctly with the umlauts in the phone, but adds
> > two more random characters. It seems to be a relation between the number
> > of umlauts and the number of added characters. I assume, that libgnokii
> > does something wrong with the result of the strlen() functions (which
> > does not correctly handles unicode input). This happed both with SUSE's
> > libgnokii 0.6.0 and gnokii's 0.6.1 CVS version. Pawel, maybe you have
> > any idea what could be wrong ?
> 
> As I said in the other email. Could you please show me the dump? I'll try
> to reprodyce this.

Ok, here is Mr. Jürgen Öhme, street: Öhne Gründ:

halden2:/home/cvs/gnokii # gnokii --version
GNOKII Version 0.6.0
.....
kaddressbook: WARNING: Try to write entry 'Jürgen Öhme' at phone_entry_no=155, 
phone_count=154
Reading phonebook location (155)
Message sent: 0x03 / 0x0012
00 01 00 07 01 01 00 01 02 05 00 00 00 00 00 9b |
00 00                                           |
Message received: 0x03 / 0x000e
01 46 00 08 00 01 0f 00 00 08 33 00 00 00       |  F        3
Received message type 03
kaddressbook: WARNING: Write #155: name=Jürgen Öhme, number=02102
kaddressbook: WARNING:  SubTel #0: entry_type=11, number_type=6, number=02102
kaddressbook: WARNING:  SubTel #1: entry_type=9, number_type=0, 
number=;;Hansastraße 1;Öhne Gründ;;0;
Writing phonebook entry Jürgen Öhme...
Message sent: 0x03 / 0x009a
00 01 00 0b 00 01 01 00 00 10 02 05 00 9b 00 00 |
00 00 00 00 00 04 07 00 00 20 ff 1a 00 4a 00 fc |              J
00 72 00 67 00 65 00 6e 00 20 00 d6 00 68 00 6d |  r g e n     h m
00 65 00 00 00 00 1e 00 00 08 ff 06 00 55 0b 00 |  e           U
00 14 ff 06 00 00 00 0a 00 30 00 32 00 31 00 30 |          0 2 1 0
00 32 09 00 00 48 ff 42 00 3b 00 3b 00 48 00 61 |  2   H B ; ; H a
00 6e 00 73 00 61 00 73 00 74 00 72 00 61 00 df |  n s a s t r a
00 65 00 20 00 31 00 3b 00 d6 00 68 00 6e 00 65 |  e   1 ;   h n e
00 20 00 47 00 72 00 fc 00 6e 00 64 00 3b 00 3b |    G r   n d ; ;
00 30 00 3b 00 00 00 00 00 00                   |  0 ;
Message received: 0x03 / 0x0016
01 46 00 0c 00 01 04 00 00 10 03 00 00 9b 00 00 |  F
00 00 05 00 00 00                               |
Received message type 03
kaddressbook: WARNING: GNOKII export filter finished.
Serial device: closing device

> > The gnokii API was changed incompatible with gnokii-0.6.1 (CVS) from
> > gn_cfg_read(char **bindir)   to  gn_cfg_read(char *filename, char **bindir);
> > Could you please either change it back and make it compatible again ?
> 
> Is it really a problem? 

Yes, it is. Applications would need to #ifdef code and that is really ugly.

> If so I'll revert it, but also the bindir argument is a subject to be gone 
> soon...

No problem, if you choose a #define LIBGNOKII_VERSION and then go to a stable 
and clean api.

> > Or, please add a GNOKII-specific numeric #define with which external apps 
> > might get a chance to choose the right functions.
> > E.g. please add
> > + #define GNOKII_VERSION 0x061
> > to include/gnokii.h ?
> 
> Well, we have libtool doing some magic in common/Makefile:
> LIBTOOL_VER = -version-info $(MAJOR_NUMBER):$(MINOR_NUMBER):0
> LIBTOOL_RPATH=-rpath $(libdir)
> 
> Isn't it enough? 

No really. It produces a #define VERSION "0.6.1" (or similiar), and this 
"VERSION" define is a) a string and not usable for #ifdefs, and b) not included 
in distros, since it's not a unique name.

> But yes, adding GNOKII_VERSION (or rather 
> LIBGNOKII_VERSION is not a problem.

Yes, please add #define LIBGNOKII_VERSION 0x601 (or similiar).

Helge




reply via email to

[Prev in Thread] Current Thread [Next in Thread]