> Dimitri, I'm still not sure if you spell your name
> with a 'y' or 'i' at the end
I would prefer the 'y'.
> How are we planning to handle extension packages with a high degree of
> dependancy? For example, say we have an extension for 'Cloud' and another
> for 'DropShadowText', and yet another for a 'BlackStrikeThrough'. Now if a
> particular node has all these effects, we have to make sure that the
> effects are rendered in the right order (Cloud,ShadowText,Strike) or else
> they overdraw one another. How are these dependancies planned to be
> handled? This could apply to other non-formatting dependencies as well,
> like if one extension sets a particular attribute and another uses that
> attribute for formatting, then the setter should run before the formatter.
Thank you for your very good questions, which have not been discussed until now. If I understand you correct, it is all about how different node properties are rendered in a right way.
I could propose a solution which I believe to be easy and pragmatic. The standard node rendering components (NodeView) should not have extensions like model or controller components. They always own one MainView component for painting of the node's form, text, icons, background and selection background. The MainViews depend on many node property packages (as they interpret text, font, color, icons), but they only read them and do not change them directly.
The NodeViews are responsible for its own layout including positioning of the child nodes and painting of the clouds and the outcoming edges. (It means that they can read the information from appropriate node extension objects like node shifts, clouds or edges). They can be extended by adding further rendering components like AttributeTable or Latex Viewer (HotEqn) coming from extensions, which also are usual awt or swing components (JComponent) painting themselves. So attaching and painting of arbitrary new node property elements is possible.
You see that design of the rendering component packages is a bit different from the design of the model or controller packages. IMHO it is so because
* the renderer components are usually derived from JComponent or awt.Component,
* they are quite memory intensive,
* they essential task of the rendering component is the rendering of the effects in the right order,
* complexity of the rendering component is smaller than complexity of the controller packages with all actions and listeners defined there, and they do not have to be split