Re: vcard-integration for gnome



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.

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