[Uml-devel] Re: Umbrello design (was UML XML tree viewer)

[Luis De la Parra]

> My guess it that they designed it with a pattern known as the composite 
> pattern. So basically, a PresentatinElement can present a certain aspect 
> >from the model. But it can also consist of several other 

yeah, I think you're right.

> Yes, virtual inheritance cna make you day for this kind of situation. 
> However, if improperly used, you can get in some situations where you 
> don't even understand what your own code does (or is supposed to do). 

we should probably take a closer look at this,  but I dont think we are
going
to have any problems there. The Signal/Slot mechanism needs basically a
pointer
to the object and some kind of "virtual function table" generated my the
moc... and that's
what we are going to use QObject mostly for, so as long as there is only one
QObject
component in each UML/MOF/Whaterver-object, everything should be ok, and
that's what
virtual hineritance is for.

> >
> With kpart, I thought you could also install a small XML file describing 
> some actions you can take on your kpart when displayed in a "foreign" 
> container like konq or kword.

yes, you describe the actions in a XML file, but not only for "foreign"
containers.
you use exactly the same method for your "native" application.

> So I thought the application would be a 
> kpart, with a menu letting you select the diagram in that UML file 
> containing the diagrams.
> I don't see what we gain in having a kpart for each type of diagram...
> 

actually the Diagrams should be a KPart, the CodeGenerators, libXXX and
friends
should be a Plugin, and Umbrello would be only a KPart-container, which
loads the appropiate
Parts and Plugins...
the only thing we need to think about is that this is not so direct, because
of the Document/View model
we want to have.

--> We will have a Model (or a MainPackage or whatever its called=) where
everything lives 
-->Each diagram is a "View" of this modell  (all the diagrams are really
viewing at the same model
    only from a different point of view) so that if you change a class
through a ClassDiagram this changes
   are reflected in a colaborationDiagram using objects of that class
-->There will be something like the current UMLListView -- (I would call it
ModelBrowser, because it
   shows you the elements in your model, and lets you "navigate" trough
them)..... again, this thing is also
   just a view on the same model

The problem is that all diagrams and the ModelBrower have to be connected to
the same model, so you cannot create
a completly independet Part for each of them...
I read a little about KParts a couple of days ago, and it turns out that the
part is not really the widget --as I used to think--
but the Part *has* a widget, among other things (menu items, toolbar
buttons, actions, other widgets). 

one possible solution I've been thinking is to make the Model object a KPart
which has a method
"createView(diagramName)" which creates and returns the diagram.
 --I think this is more or less what KOffice does,
since they are KParts and they also can have different views acting on a
document.... but our case is more complicated
because all their views look at the document from the same point of view,
and in our case each diagram is a different point
of view of the model.--

KParts have to implement a method openURL() which is what the container
calls, so I thouht the "default"
view would be the ModelBrowser, so that if you click a umbrello file in
Konqueror, you get the ModelBrowser, and
when you click on a specific diagram, you get the diagram.
... if you want to see a specific diagram right away you can call
openURL("myFile.xmi?diagram=myColabDiagram")

Umbrello would be a Part container.. just like a shell which embedds the
ModelBrowser, the different Containers, and loads the
necessary plug ins.


luis

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!