Re: [Gnumed-devel] GNUmed+ KOrganizer

[Syan Tan]

what are the details of the data structures and access api from the
kde point of view?

On Thu Mar 15 14:47 , Kevin Krammer <address@hidden> sent:

>Hello GNUmed developers,
>
>
>
>I'm sorry it took so long to prepare a reply to Karsten's info about 
>
>integration requirements, I'll try to also address some of the issues you 
>
>have according to the mailinglist archives.
>
>
>
>Basically I approached Karsten at a German Linux event and mentioned that an 
>
>integration/interaction with KOrganizer might qualify as a student project 
>
>for Google's Summer of Code, where KDE will once again be a mentoring 
>
>organisation.
>
>
>
>Just doing KOrganizer interaction is unlikely enough for this purpose, since 
>
>the students should have enough work for about three months "full time".
>
>
>
>However, depending on your needs and goals, it might be an option to extend 
>
>this into a more generic PIM (personal information management) integration, 
>
>i.e. appointments, contacts, possibly syncing with PDAs, etc.
>
>
>
>For any such integration there are basically two options:
>
>
>
>1) GNUmed being the data source and KDE applications being used to handle 
>
>visualization/input
>
>
>
>2) KDE being the data source and the front end and GNUmed delegating tasks to 
>
>KDE's PIM applications
>
>
>
>ad 1)
>
>KDE's PIM applications, e.g. addressbook, organizer, can have plugin based 
>
>data sources (called resources) and if you already have the respective PIM 
>
>data in your postgres database, handling this data through KDE applications 
>
>should be doable by providing KDE PIM resource plugins which access your 
>
>database.
>
>
>
>ad 2)
>
>this approach is closer to Karsten's suggestion of "remote" controlling 
>
>KOrganizer through the DCOP inter-process-communication interface.
>
>From KDE's point of view this would be interesting in the sense of GNUmed 
>
>being an ISV (independent software vendor) integrating with our platform, 
>
>something we want to emphasise and encourage in the upcoming KDE4 era.
>
>
>
>Option (1) has the advantage that you stay in control of the data, i.e. a user 
>
>can always switch to a different front end, option (2) has the advantage that 
>
>the respective PIM framework can usually handle a variety of storage options, 
>
>e.g. local files, groupware server, etc.
>
>
>
>Some of the questions I saw  in the archives:
>
>
>
>- can KOrganizer run without "full KDE": one does not need to run a KDE 
>
>desktop session in order to use KDE applications, for example it is quite 
>
>common that usersof other desktop environments use K3b for CD burning or 
>
>Amarok for music playing
>
>
>
>- what if KOrganizer isn't installed: as Karsten already mentioned, this can 
>
>be detected at runtime.
>
>
>
>- what to do on proprietary platforms, e.g. Windows: neither KDE nor 
>
>KOrganizer are currently available on Windows (only available as X11 
>
>applications on Mac OSX). This will be an option once KDE4.0 is released, but 
>
>this is likely too far in the future for your needs (depends on your 
>
>timeframe for this kind of features)
>
>
>
>Cheers,
>
>Kevin
>
>
>
>-- 
>
>Kevin Krammer, KDE developer, xdg-utils developer
>
>KDE user support, developer mentoring
>