[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-11-07 18:48:48
[Download RAW message or body]


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

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

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

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

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

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.

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





__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.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]