[Uml-devel] WidgetSet / Widgets plug-in

[Luis De la Parra Blum]

Hi all,

a while ago I had tried to convert the widgets from my expeimental diagramming 
code into some kind of plug in, so that the way widgets are rendered could be 
changed at run time without having to touch the app itself.

I had a lot of problems building it and even a quick read of the autobook 
didnt bring me forwards, so I could never get it to build....till yesterday.
last night I stole some configure/make files from andy's umbrello2 and after 
minor tweaking I got it to build.

While it does very little now, I think it's interesting so I thought I'd share 
it with you.

here's what it does:
- when the Diagram gets a request to create a widget, it forwards it to the 
WidgetFactory, which in turs queries all loaded plugins to see if they 
can/want to handle the request.
- the first plug in who wants to handle the request creates the widget and 
returns it to the diagram.

As example I created a plug-in that handles classes for web-applications. 
this example plugin decides if it wants to handle the request based on the 
class' stereotype (it accepts all UMLClasses which have an stereotype = 
"WebPage" and rejects all other requests)
the widget is drawn almost identical to the ClassWidget (thank god for copy 
and paste! =) , with the only differences being the color and a small web-pix 
on the top-right corner, but of course the drawing functions (and all others) 
could do whatever they want.

I dont know if this is usefull / interesting for Umbrello right now, but I 
think we're going to need something like this for U2, specially if we base on 
QCanvas or Karbon
I can imagine having a "UMLWidgetSet" plugin, which would be loaded when the 
UML model is loaded, and some other widgetsets for the different models, plus 
a "CustomWidgetSet" for drawing boxes, lines, texts and so on

some open points are:
right now, once a widget is creating to represent an umlobject, it will 
continue showing it even if the object has changed in a way which would make 
the widget "unsuitable" for it. This means that, for example, if you change 
the stereotype from "WebPage" to "something_else" the widget will still be 
drawn as a web page, and if you create a widget for a class and then set it's 
stereotype to "WebPage" it will continue being drawn like a normal class or 
by the plugin that accepted the request at widget creation time.

giving up the control of a widget would be easy to implement (react to the 
object's modified signal, and if it doesnt meet our requirements anymore, ask 
the diagram to replace the widget with another)
the other way around could also be implemented, but right now I cannot think 
of an efficient way to do it ( I would not like to ask every single plug-in 
if they want to handle the request everytime an object changes to see if 
there is a "better match" for the object now)

if you want the widgets to change "dynamically" based on the object 
attributes, we'd have to find a way around those problems, but if we want the 
widgets to be stable (ie, not based on Stereotypes or tags, but only on 
object type) then we'd have no problem.

what else....
ah ja, I changed my "custom lib loading" for andy's plugin loader and it seems 
to work quite good. the only thing I'd like to change is making the menu 
entries XML-based instead of hard-coding it, like the KParts plugin, that way 
we could also add buttons to the toolbars based on the XMI files ( when you 
load the "customwidgets" buttons for boxes, lines and texts appear on the 
toolbar, when you load the uml_widgets plugin, you get "classes" and "actors" 
in the toolbar )

so... I think this will be something worth looking at for u2 (maybe changing 
the DiagramElement to be a VObject instead of a QCanvasObject), but maybe it 
could also be of interest for u1 ... the problem is that since it's based on 
my experimental diagram classes, it's not compatible with the old widgets, 
and we'd need to implement the missing functionality in the new code  
basically :
-loading/saving using the format of the current widgets (easy),
- fixing the associations (difficult),
-implementing the drawing functions for all other objects (right now only 
classes are implemented but the rest should be easy)

ok, that's about it.
the changes to the current code are small, but I had to add two automake 
"directives" so that it exports symbol information for the plugins to use.

if someone wants to test it, here the instructions:

*grab the uwdk from the developer's section.
 ( Umbrello Widget Development Kit ) 

*build and install the uwdk as normal. ( including make -f Makefile.cvs )

*add folowing lines to your umbrellorc file
[Plugin]
widget_sets=libwebwidgets

*start umbrello, and create some classes. then set the stereotype of some of 
them to "WebPage" and drag them into a class diagram (the "new" class 
diagram)

*voila: the classes marked as "WebPage" are handled by the plugin (normal 
color, with a small icon) and the others are handled by the built-in widgets 
(green)

-->like I said, once the widgets are created they are not changed, so if you 
create a class through the class diagram and then change it's stereotype the 
widget won't change, so you have to create the widget based on an object that 
already  has the stereotype at widget's creation time.... the easiest way is 
by setting the stereotype and then dragging from the listview.

if someone does try this, I'd like to hear any comments.

saludos,

luis