[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-08 1:44:28
[Download RAW message or body]

On Wednesday 07 November 2001 19:48, Bryan Brunton wrote:
> << Why do you want to reinvent the wheel to be portable? >>
>
> I'm not sure that I can agree with that.  There are sigificant KDE
> dependencies in an app like KOrganizer.  Re-inventing all of those
> dependencies would seem to be the real re-inventing that would have
> to do on here.

I do know the dependencies of KOrganizer on KDE ;-). Trust me, it's not 
a big problem to replace these by portable solutions.

> << The database-aware widgets might be easy to
> use for small projects, but in the long term it will become a problem
> to tie the GUI to the storage layer. One example are daemon-like
> programs, which operate on your address book or calendar data, you
> have to rewrite everything to make such a program to not require a
> running X server. This is a nightmare to maintain. With the level of
> abstraction provided by the APIs of kde-pim this can be solved in a
> much more clean way. >>
>
> The only X dependant parts of the QT DB API that I am using might be
> QSqlForm.  There would be no difficulty in using the lower level
> pieces of QT DB API in standalone daemon-like programs.

Yes, but this is nothing more than just accessing the database. You 
still have to make sure that the correct entries are used and that they 
are used in a consistent way.

> << The right abstraction layers eliminate points of failures, because
> they reduce code duplication and dependencies. >>
>
> Yes, but they also introduce another layer that needs to be updated
> and maintained and understood by anyone who wants to add to the
> application.  Potentially, in my application if a user wants to add a
> field to a data entry form he will: (1) create the database field,
> (2) open and edit the form in QT Designer.  99% of C++ and QT aware
> programmers will be able to do this in minutes/seconds.

The abstraction layer, which is provided by kde-pim, makes you 
independent of database fields and similar things. For example you 
don't have to make an SQL query on a field "NAME", you just call a 
function name(), independent of the storage method, and all other 
applications have to do it in the same way. This means data is used 
consistently and without duplicating things like field names all over 
the code.

> Adding a new field to the KOrganizer todo dialog would take how long?

Just adding a new field takes a few minutes, but you gain nothing from 
it. The data has to be used in a sensible way and an abtract layer 
above the data makes sure that all applications mean the same thing 
when handling a certain kind of data.. As said before, the backend 
isn't that important. The application logic and GUI has to make sense 
of the data, just adding more fields does not add any functionality 
better than what is provided by such simple things as plain text files.

> << In addition to that you have to solve the problem of
> interoperability. >>
>
> There is a problem with interoperability.  My UI will only play
> nicely with my data.  However, my goal isn't to shoot for the Moon. 
> Like I said I am not designing the next generation of groupware.

You said you would like to provide an alternative to Outlook and 
Evolution. These two focus strongly on interoperability.

> We simply have two different design solutions.  While my application
> will be simpler and potentially less interopable, I can easily
> guarantee a few things that the current KDEPIM suite cannot:
>
> (1) speed of development.  In a few short hours of work (usually late
> at night after my day job), I have nearly duplicated KAddressBook and
> the ToDo functionality of KOrganizer. (2) cross platform.
> (3) easily extensible.  I can easily add on to my application.  I
> plan on building legal case management functionality on top of the
> contact/task/calendar base. (4) and finally, fill the KDE-side demand
> for an integrated Outlook/Evolution solution.

(1) is not fair. You are not compatible with all KDE apps using the 
common KDE address book and you don't provide things like syncing the 
Todo list with PDAs.
(2) is not a big problem. Making kde-pim cross-platform is less work 
than usually expected.
(3) Extensibility is provided by all kde-pim apps as well. I don't see 
a problem with building a legal case management on top of the existing 
KDE solutions.
(4) As said before, you are not the first one attempting to provide 
such a beast. Building on the existing kde-pim applications might be  
better than creating everything from scratch.

> IMO, I don't see KDEPIM ever fulfilling #4.  But then again, that
> might not be its goal.

We don't want to write yet another Outlook clone. We want to provide 
the real solution: individual apps, which can work together to provide 
the same functionality as an visually integrated app, but without the 
overhead and other disadvantages.

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