[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 21:04:17
[Download RAW message or body]


<< i like your ideas, and you're going the right direction for 
stuff i was thinking about yesterday. the only differenct is the eventual 
endpoint that an application like that could be used for (two different \
needs  with a common backbone. >>

I really need to come up with a name for the Contact/Task/Calendar \
management application to differentiate it from VirtuaLaw.  VirtuaLaw, as a \
legal case management system, will use the contact/task/calendar \
functionality.  It will add additional functionality for managing cases, \
doing legal billing, etc.  They will however be entirely different \
applications.

The contact/task/calendar application can be viewed as a backbone on which \
other applications could be built.  IMO, the level of integration required \
goes way beyond the "plug-in" methodology that has been espoused by KDEPIM \
people here.  I can't agree that you can build meaningful integration on \
top of a contact/task/calendar application using plug-ins.  By meaningful I \
mean far reaching application functionality that changes or adds to the \
idea of what a contact or task is, and how they interact with additional \
functional components.  Doing plug-in integration like this and maintaining \
a useable UI is real hard.

<< that's what i do for a living - but it sounds to me like you're missing \
a layer. >>

What you describe here is the ideal.  I simple don't the have time and or \
inclination to design the ideal multi-tiered application.  I am also \
attempting to make this as simple a design as possible.  I am using QT3 \
databound widgets.  These talk directly to database drivers so a truly \
separated middle layer isn't possible.  I have, however, separated most of \
the business logic into classes that will allow the use of different \
databases (anything that QT supports) on the back end and provide for \
separation between presentation and domain.

<< alternatively, you could use a web browser to see your contacts. >>

I have considered doing a PHP based interface to this system as I have lots \
of PHP experience.

<< things like security: who can update personal information? who can \
access personal information?
> > 

As the system is going to be multi-user, I have definitely planned on \
implementing a roles based security system

<< if you're interested in having another developer >>

Anyone who wants to help is welcome.  I should acknowledge that the goal, \
at least for the initial release, is to make as simple and functional a \
multi-user contact/task/calendar management tool as possible.  I won't be \
entering into an Aethera-like quaqmire.  I am not designing the next \
generation of contact management application servers.  With that \
acknowledged, I think that given the ease with which I progressed so far, I \
can have a functional, multi-user contact/task/calendar management system \
released in a few months time.  Possibly three to four months after that I \
can have basic email integrated into the system.  People will have a choice \
other than Evolution for an integrated open source system like this on \
Linux.







__________________________________________________
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]