Re: vcard-integration for gnome

[Guido Schimmels <guido schimmels freenet de>]

Am 22.11.2003 21:19:05 schrieb(en) Darko Obradovic:
> Am 22.11.2003 01:06 schrieb(en) Guido Schimmels:
> > I've been missing a stand-alone contact manager too, so I started to  
> > work on one last month. But it is written for the ROX-Desktop, which  
> > is based on Gnome technology, but it's a desktop shell of its own.
> > I would however be willing to maintain a Gnome-HIG compliant version  
> > in parallel, if there was enough interest. It's a small app and will  
> > stay that way, so that wouldn't be a big deal.
>
> Sounds good. I was searching for Rox and this page  
> http://roxos.sunsite.dk/ looks more like it is a whole OS... *g* What  
> does it share with gnome? Only GTK2, or some more libs? What's the  
> difference? A link would be enough.

http://rox.sourceforge.net/phpwiki/index.php/HomePage

> > As for "architecture". Heaven, you people always think way too  
> > complicated. Currently my application stores all contacts as  
> > seperate vcards into ~/Contacts. Create a ContactsPath gconf-key, so  
> > you can include different sources, and you have your "architecture".
>
> Who ever said an architecture can't be simple? Sorry, but creating  
> them is kind of my business, so I always think in this term. I like  
> your approach (hey, it's 99% similar to mine! *g*), but you should  
> think about some advanced details before they catch you. Does it make  
> sense to have directory user-visible?

One of the reasons I store contacts as individual files is to make them  
managable with the file-manager, instead of locking them into some  
application. Then it would be silly to hide them. Another reason is the  
same reason why every modern mail client should use Maildir instead of  
mbox - robustness against data loss and processing speed.

> How about Localization
> therefor?

I plan to make it configurable and pick a default according to the  
locale settings. We must agree on a desktop wide gconf-key for that,
hence I suggested a "ContactsPath" key.

> From the spec, more than one vcard in a file MUST be
> supported, so still stick with multiple files by default?

I have to think about how to handle that. One option I see - for my  
application at least - when it detects such a card it offers to add it  
to the folder(s) as individual cards. The interface is not designed to  
view such cards. If viewing without prior splitting is an important  
feature I would need to make some bigger changes.


> > Here is my "Contacts" app:
> > http://roxos.sunsite.dk/dev-contrib/guido/Contacts/
> >
> > (click on AppRun inside, to launch it, if you are not using ROX- 
> > Filer)
>
> sorry, I have neither Rox-lib nor python-gnome here.

You can get it here:
http://rox.sourceforge.net/rox_lib.html
Simply untar it and drop the whole directory into /usr/local/lib or / 
usr/lib.

Are you running some self-baked Linux? gnome-python should be readily  
available for every distribution.

> The screenshot only shows a gui for editing one contact. Does your  
> app have a main window, or do you rely on selecting files in the  
> file-manager?

Exactly. The screenshot shows everything there is to see. Just click on  
a vcard in the file-manager to view it. I'm in the process of adding a  
search facility. The toolbar item is already there but not yet  
functional. The idea is to reuse the interface as a search form. The  
program will do a fuzzy search over the fields where you entered text.
If it finds only one match, it will load the card into the current  
window right away. When there are several matches, it will create a  
folder with symlinks pointing to them and pop up this folder. Real live  
queries would be much cooler of course. But symlinks will do.  
Autocompletion would be great also. But this sounds a bit more  
complicated.

> Did you use any lib for handling vcards, or do you expect every app  
> to do that on it's own?

The parser is written ad hoc with the spec open in another vim window.  
That's real easy in python. Originally I was reading the properties  
directly into the text-entries. To prepare for the search facility I  
now load the card into a python dictionary (hash-table) as an  
intermediate step. I guess this could be easily factored out into a  
reusable class. But then it is still python code, sorry.