[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Storing of presentation data (was Re:Tasks to be done)
From:       Thomas Förster <foerster () itb ! biologie ! hu-berlin ! de>
Date:       2001-03-22 7:56:00
[Download RAW message or body]

On Wed, 21 Mar 2001 Gerard wrote:
>   As far as I can tell you have full permissions for the Task Manager.

Thanks a lot, today I have no problems yet. so this was indeed a sourceforge
problem.

>My only comment for the moment is that I don't think defining the API is
>much of an issue because we're using the IDL defined by the UML spec
>(well there is the question of how to store presentation data).

But is has to be done. If it's nearly complete, the better. I think that
storing presentation data is no issue for the library. I would opt for putting
all presentation data as "PresentationElement" into the repository. The
attributes will be stored as Extensions (I don't know the exact UML class and
have no Spec at hand now). It's the clients problem to get the needed
information out of the extensions. But this would allow even incompatible
clients to use the same model in the repository.

>In fact if I'm not mistaken the code Chris has uploaded already 
>implements much of that API.  So it seems to me that's what's needed is 
>for somebody to start writing a prototype client that uses the 
>repository at least for storing model data.  This will hopefully lead to 
>a better understanding of how the client and library interact and what 
>is needed for the presentation data.

>   I would think that the fastest approach would be to reuse code or at 
>least architecture from some existing GPLed diagram editor (for example 
>dia (but its in C/GTK) or kivio).

So it seems the 50% complete I gave the task today are to low already now. ;-)

[prev in list] [next in list] [prev in thread] [next in thread]