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

List:       kde-pim
Subject:    Re: [Kde-pim] Minimum requirements to make a QT app into a KDE app?
From:       Bryan Brunton <bryanbrun () yahoo ! com>
Date:       2001-10-31 17:13:17
[Download RAW message or body]


<< Consider that your application is competing with KAddressbook and
KOrganizer. Therefore some compatibility is essential. In particular there
are applications that rely on the existence of the DCOP interfaces of
KAddressbook and KOrganizer for their operation. Take them into account. >>

I'd like to have as much compatibility as possible.  Who knows, potentially have the ability to
add folder types that are KAddressbook or KOganizer.  That's kinda a distant dream at this point. 
The few sticking points are:

(1) my application is cross platform.  Initially I am designing it to be portable to Windows/Mac. 
Additional KDE integration will have to come later.  Right now just aiming for the minimum. 
Eventually some import and export mechanism from the KDE apps would be nice.  Obviously some
levels of KDE integration (such as DCOP) might not be possible.

(2) my application is a multiuser client/server application using QT3 database support.  While
KDEPIM suite shows great potential, the amount of code and hackery required for functionality that
essentially re-implements old school database application functionality is significant and, IMO,
kludgey.  Here on the client side I am talking about things like databound widgets in QT3.  Then
on the backend side there are significant things like record locking and data integrity that I
don't think the current KDEPIM suite can guarantee.  Obviously, the KDEPIM applications are single
user so these robustness issues are not as significant, but the amount of code required to write a
simple application like KAddressBook is alarming.

But I'm very ignorant about the KDEPIM suite, most of my talk here is conjecture.  Perhaps the
address book API allows the use of a real database server as a backend?  But then I would be
concerned that using such an API inserts another point of failure, another code base that needs to
be updated, a code base that could never evolve fast enough the applications it servers.

Essentially I am concerned that the KDEPIM suite can NEVER provide robust multi-user applications
without putting in support for the use of a traditional database server on the back-end.  I think
that potentially there is a danger of re-inventing the wheel in an entirely unsatisfactory manner
(such as the horrible virtual file system solution that Aethera tried to use).

<< Oh, and your screenshot suggests that a person can only have about 4 phone
numbers, one for each of home work fax and mobile. That's a bit of a
limitation. >>

Much about the app at this point is pre-alpha, the task and contact dialogs in particular. 
Eventually I'll have drop downs so you can select the phone number type of each of the four phone
numbers, just like Outlook and KAddressBook.  IMO, while its great that the KDAddressBook 2 UI for
phone numbers and address allows you to enter in many multiples of phone numbers and address, I
think that the UI it has for doing so is clumsy.  The original KAddressBook UI is superior.

If a user wants more than four phone numbers then that will probably go into the notes field or
into a custom field.  The UI sacrifice that KAddressBook 2 made in this respect just isn't worth
it.





__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim

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