Re: vcard-integration for gnome
- From: Guido Schimmels <guido schimmels freenet de>
- To: desktop-devel-list gnome org
- Subject: Re: vcard-integration for gnome
- Date: Sat, 22 Nov 2003 23:13:45 +0100
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.
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
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:
(click on AppRun inside, to launch it, if you are not using ROX-
sorry, I have neither Rox-lib nor python-gnome here.
You can get it here:
Simply untar it and drop the whole directory into /usr/local/lib or /
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
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
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.
] [Thread Prev