Hi Nicolai,

thank you for your answer, I will try to explain my problem little bit further/better.

Let's take a simple example of bordered box full of lines of text.

--------------
labels := OrderedCollection new asValueHolder.

view := RTView new.

group := RTGroup new.
box := (RTBox new color: Color white; borderColor: Color black) element.

RTNest new on: box nest: group.

labels whenChangedDo: [ :collection |
group do: [ :each | each remove ].
group removeAll.
group addAll: (RTLabel new elementsOn: collection).
view addAll: group.
RTNest new layout: RTVerticalLineLayout; centerOn: box elements: group.
RTNest new layout: RTVerticalLineLayout; centerOn: box elements: group.
view signalUpdate.
].

view add: box.
view open.

labels add: 'first'.
labels add: 'second'.
labels at: 1 put: 'First line'.
labels removeLast.
-------------

My first problem with this approach is that its adds multiple elements to the view, so I cannot do any RTLayout on: view elements, since it would apply it to everything. For example RTLabelled interaction adds TRLabelShape instead of RTLabel, maybe to prevent this kind of problem?

And the second issue is that the builder is essentially just a pass-through thing - just applying some rules on the elements but not really tying them together. I would prefer to have the whole element somewhat more tightly coupled. Done this way it is bound only by some TRCallbacks created inside RTNest, so technically they are connected only through box's trachelShape, which I feel isn't even the appropriate abstraction level (as you yourself have pointed out).
So thus my call for custom RTShape or something similar. Maybe it would be more appropriate to subclass RTElement and RTEdge?
What I am trying to do is not just visualization (as done by Moose) but a live (diagram) editor.

Peter

On Sun, Oct 5, 2014 at 6:52 PM, Nicolai Hess <nicolaihess@web.de> wrote:
Hi Peter,

I would say, stay at the RTShape level. Trachel objects are for the low level stuff. For example a
TRArcShape defines an arc based on the geometric property and with RTShapes you visualize a model
by mapping its attributes to geometric values for the visible (trachel ) shapes.

An UML class diagram is a rectangle with three segments (or three boxes). The mapping from class attributes
to the class diagram would happen on with RTShape/element/builder...., so you would need something on that level anyway.

Sure you can define a UML-Trachel shape as one geometric object. But I would only choose this
way if the object is somehow "static" and "closed".If you want to change the object(model) through the
visible representation or connect parts of it with other elements, then every single element of the
UML-diagram (class label, class vars, class methods) should be accessible on the RT-Level.

I wouldn't subclass RTShape neither. The whole framework looks like it is based on builders and
building complex shapes as groups of simpler (RT)shapes.

Maybe something like a group of three RTBoxes. The first box only has a label, the second
and third box has a list of other elements (vars/methods).

In addition the two other boxes may have different states.
Collapsed (only shows the attribute (var or methods) and the number of elements
Expanded (show a full list, this may be difficult for classes with many methods roassal shapes do
not provide something like a scrollable list)
Expanded overview (somethink like the "blueprint" diagram, wiith small single boxes for every item)


I would start by looking at the "Pharo Smart Browser" (In the Roassal2 image)
It defines boxes for classes and within this (expanded) boxes is a list of
trees for the methods, for an UML - Diagramm you'll use a list of labels for the methods).


Nicolai







2014-10-03 22:03 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
Hi,

I am wondering what is the proper level at which should be addressed composition of elements.

Imagine I want to create a diagram of UML class but I want to be able to dynamically add and remove new lines and sections, including various formatting (underline, italics, bold, ...) of each line separately. The RTUMLClassBuilder (or any other builder for that matter) is not an option since it's a one time build.

The option I see is to subclass RTShape (let's name it MyRTUmlClass) and implement method trachelShapeFor: .
Now the issue is, that I cannot use other RTShape (Roassal) elements, because they would have to be inserted into RTView which may not be available at the time - is there a way around it?

So the other option is to use TRShape (Trachel) elements instead which would be fine except I feel like I am duplicating code of roassal elements (so for TRLabelShape I would copy RTLabel trachelShapeFor: and bend it for my needs), and the second issue is that in updateFor:trachelShape: I would need to access internal structure of the element and change it (because for example a new method was added) - does that break encapsulation?

And finally, from conceptual standpoint what should be the content of RTView elements? Because if I have diagram full of UML classes I probably don't care about the content of them when doing layouting - so I would prefer to have only MyRTUmlClass elements there and not every single label inside it (as is the case of RTUmlClassBuilder), because otherwise having access to RTView elements is useless and I must keep reference to correct objects myself.

Thanks!

Peter

p.s.: Is it currently possible to format text? I saw only color, font and size... what about underline/italics/bold?


_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev