[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: Status report #2
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-08-23 14:20:07
[Download RAW message or body]

On Mon, 23 Aug 1999, Don Sanders wrote:

> The sort dialog strikes me as a little dumb but the other dialogs have merit.
> The filter dialog (which maybe can double as a find dialog) looks like it
> would be a fair amount of work to implement (at least compared to the sort and
> field selection dialogs). Rik has suggest extending kfind with pim
> searching capablilites, I wonder if kfind is being actively maintained?

Whether it is or not (it looks identical in HEAD to KDE_1_1_BRANCH so I'd say
not) I'll do the work on it when it's time, unless someone else is keen.

> At some point the addressbook GUI will be wrapped up and put in an openpart as
> will other pim parts (like a mail client and calendar). We hope to use
> openparts to allow the user to choose which components they which to include in
> their pim. This will also allow for competing implementations of pim parts (and
> pim containers too). So if you don't like the sound of commoditizing the MS
> outlook addressbook you are free to develop an alternative addressbook
> implementation. If you are interested in commoditizing MS outlook
> then tell me which bit you are interested in so that I won't duplicate your
> work.

I hope you meant 'alternative addressbook UI implementation'. The addressbook
itself is supposed to be shared throughout KDE and using a different
implementation would mean you wouldn't be able to share data. Making a
different UI breaks nothing except perhaps some consistency. Teddy said
he will be wanting to do this with Magellan.

> Beyond the addressbook are the issues of integrating KOrganizer (something we
> haven't talked about at all yet) and Knotes. This might be tricky. I'm
> wondering whether we should TEMPORARILY fork the development of these programs
> (Kmail too) and work on turning them into openparts (and maybe using Riks
> addressbook backend to store data in). I say this because we may have to break
> these programs quite severely before we can divide the code into an inside part
> (the openpart) and an outside part. Perhaps we can win favour by helping port
> these apps to the HEAD branch and enhanching them (I'm prepared to help do
> this, I will have a lot to learn about).

I don't like the idea of using the addressbook backend to store anything other
than addressbook data, but actually each entity is only a name/value map, so
there's no real reason that other data couldn't be stored.

KOrgani[sz]er uses vCalendar as its native storage format. This provides
compatibility with other similar apps. Preston has contacted me asking what
he could do to help out doing the necessaries with KOrganiser to make it
work with the pim project. I suggested that he needs to provide a CORBA
interface for accessing the data and the GUI components.

He hasn't got back to me about whether he's going to have time for these
sort of things. I personally don't think I have the time to port KOrganiser (if
it isn't already) or CORBA-ify it, but we'll see later on after I do Empath.

KNotes is so simple that it might actually be a good idea for me to do a CORBA
interface for it right now, to get some practice before I attempt it with
Empath (again).

> Hmm, my girlfriend just got here and she is engaging in attention seeking
> behaviour so I better attend to her.

'Any unfinished Open Source code can usually be blamed on the fair sex'
(paraphrased from somewhere)

I blame the design of humans myself. We need to work to eat, and we need time
to eat, and to sleep. I'm working on a redesign, with a CORBA interface...

-- 
KDE - Colour Outside The Lines - http://www.kde.org

[prev in list] [next in list] [prev in thread] [next in thread]