Re: Category support in adsressbook

[Nathan Owens <pianocomp81 yahoo com>]

--- Tom Billiet <mouse256 ulyssis org> wrote:
> ----- Original Message -----
> From: Tom Billiet
> Time: 08-01-07 15:54
> > Hi,
> >
> > I'm currently looking if it's possible to add category support for the
> > addressbook when syncing with evolution.  As far as I found there is
> > currently no support for it, so I started looking at the code trying
> > to hack it myself :-)

Great! We need this!

> > But I'm a bit confused understanding the code. I think the most
> > important things need to be changed in the addressbook conduit file
> > from evolution (addressbook/conduit/address-conduit.c).

You hopefully won't need to change anything but this file.
> Okay,
> To answer to my own mail: I still haven't found where the "compare" and
> "prepare" functions are called, but I noticed it's not needed. I do have
> a working category syncing now :-)

compare and prepare are called through GTK signals, as you guessed. These are setup in
conduit_get_gpilot_conduit(). They are called from the gpilotd itself during a sync. You'll want
to take a look at the pilot-link syncconduit.sgml documentation file. Also take a look at the
Tasks and Memos conduits for category syncing. It mostly works in those (there's at least 1 bug I
know of, though in bug 201167)

See http://bugzilla.gnome.org/show_bug.cgi?id=201167 for how Category Syncing was implemented for
those two conduits.

> But not too enthusiast, I still have a 3 problems left:
> 1) (the biggest problem) Every item you read from the palm has a
> category, which is a number (id). But so I have no idea what the name of
> that category is, and I can't find a function to convert that id to a
> name or get a list of all the categories in the palm. I'm sure this is
> possible, but I'm overlooking it in the pilot-link doc's, can anybody
> help me on this?

PalmOS Databases have 2 parts: an App Block and Records. The App Block contains the pilot-link
CategoryAppInfo structure (see pi-address.h and pi-appinfo.h). Each ID is a record number 0
through 15, i.e. an index into the CategoryAppInfo->name array. The category names are contained
in name[].

> 2) Evolution has support for adding an item to more than 1 category,
> palm doesn't have this support. Now I'm only using the first category
> and ignoring the rest if an item has more categories. I don't see any
> other solution.

That's essentially what I decided to do on the Tasks and Memos. The better option would be to have
a "Pilot Category" setting, and the user would choose which of the categories would be the Pilot
category. Note also that this would make it much easier to prevent the user from having more than
16 different categories that need to be synced to the PDA (each database may have at most 16
categories). I've yet to figure out how the Outlook plugin does it, but I don't think it works any
better.

> 3) Putting an item in an non-existent  category in evolution doesn't
> create a new category, but the item is added to that category
> (categories are stored as a string of comma separated values in
> evolution). So you have to create the category yourself in evolution. No
> big deal, as it will still work if the category is non-existent.  I
> haven't tried creating a new category on the palm, but I found functions
> in pilot link for doing this, so I think that won't be a big problem.
> But I first need to be able to determine whether a category is already
> available in palm, which brings me back to point 1 :-)

This was solved by the Tasks and Memos components. There's still the problem that you have to
restart Evolution itself to see the category pop-up in the Category box. This is a limitation of
the Evolution category API (or was - I haven't tested it since 2.6, and I understand there were
some improvements to the category API)

> If somebody can help me on this I can fix these problems and send my patch.

You'll want to add it to the bug I mentioned above, and probably also send it into the
evolution-patches e-mail list. If you're not already, sign up for the evolution-hackers and
evolution-patches e-mail lists. They're very useful.

I think the already-implemented examples should help you a lot. There's a lot of comonality
between the other conduits and the addressbook conduit. The main difference only comes down to the
fields and the exact Evolution APIs needed to access those fields.

There are a few other bugs (such as "File As" and Name fields not being set correctly) in the
addressbook conduit that you should probably be aware of in case you come across them. I believe
most of them are mentioned on bugzilla under the Evolution->Conduits or Evolution->Gnome Pilot &
Pilot Link components.

Hope this helps,
Nathan Owens


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com