[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-11-06 16:52:53
[Download RAW message or body]

On Wednesday 31 October 2001 22:04, Bryan Brunton wrote:
>
> 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.

Plugins are the right way for simple things where you just add some data 
fields or somthing like that. But if you have complex applications using 
contact or calendar data you still have to maintain conistency over all 
applications. So there should be some kind of integration to make sure that 
data has to be edited in only one place. If plugins for the kde-pim apps are 
not enough, one could do it the other way around and embed the kde-pim apps, 
or use the data, but let the editing be done by the specialized applications.

> << 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.

Even with the databound widgets of Qt it is possible to add a middle layer. 
These are no special widgets, but classes, which operate on the standard 
widgets. If you put this behind an abstract interface you have the middle 
layer.

> << 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.

How will you interface the PHP code to your Qt code?

> << 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.

You are not the first one attempting to write such a thing ;-). Why don't you 
join kde-pim and build on what we already have? There is already a lot of 
useful code there.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]