[kplato] resources

[Thomas Zander]

Hi,

after following your discussion I want to jump in with some general knowledge
about what is allready there, and becoming reality as we speak.

As everyone here has seen, a project like KPlato takes a lot of different
components to get right, this is the same with every big product. In KDE
we have solved most of that with transparent IO components, kparts and 
DCOP.

KIO: talking to your files via kio-slaves means you do not need to worry about
     the underlying file-storage, or even about possible encryption.
     I suggest using this since database access is just as easy as saving a
     file on your local NT-smb server using kio-slaves.

KParts: graphical components that are fully functional inside another program.
      Think a spreadsheet inside a kword document for example, or a planning
      sheet you can use in your kpresenter presentation. Auto updating and all..

DCOP: client/server connection between all applications that implement a DCOP
      client. Which are about all KDE applications. You can calculate a 
      spreadsheet in kspread via dcop commands for example. (don't know it this
      particular example is implemented, but it should be ;)


Further some components that exist and implement some functions I have seen
requested.

KOrganizer:
      Does full calendering, appointments, todo lists and is working hard 
      to do this in a groupwise matter.  (the latest CVS shows basic project
      planning features)
KDEPIM groupware-like features:
      see: http://www.slac.com/pilone/KDE-Architecture/KDE-Distributed.html

I have seen on the kde-core mailing list people who are working on
- encryption in/via kio-slaves
- kio-slaves to connect to any database.
- kio-slaves and version management.


As this exists, or is about to exist, I would like to suggest creating a core
applications KDE-style. In this way many other parts can be inserted easily
and work can be distributed more evenly among the (always sparse) developers.

And as a software developer I would suggest creating a set of data-classes first
and building a simple front-end around that. (keeping the view and the data 
seperated) in the course of building this new UI-parts can be created using
the same data and the data-model itself will start to mature at the same time.

When the simple implementation is done, consider adding saving/loading and maybe
further means of communication with other applications etc.

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new