Having a way to offset shapes is indeed important. A kind of wrapper for shapes using a
decorator.
Alexandre
On Aug 3, 2012, at 1:25 PM, Ben Coman <btc(a)openInWorld.com> wrote:
Just some additional musings... looking below at my
last post where both ROBox & ROBorder are added to a node, it seems that a node can
hold multiple shapes even if they aren't "composed." Perhaps one simpler
option that might satisfy my need would perhaps be having a ROOffsetLabel - having a
relative offset from its usual location. This would have a callback onto the model so
that several different texts could be associated with a node and dragged around with it.
An alternative might be to consider a implementing a common interactive feature of
drawing packages where multiple nodes can be selected and "grouped" into one
node which are moved around together. This might be a desirable feature overall and also
be used to composing complex shapes.
I guess another alternative would be for myself to create my own subclass of ROShape.
Now there is a second thing to consider from my example below. My #mondrianShape methods
were implemented as a method within of the model - which I think is poor OO design - but
at least got something working quickly. I think perhaps now ROShape is av- however I
require the selected shape to follow the inheritance structure of the model - by way of
example perhaps anything subclassing from MyModelContainer would have one shape and
anything subclassing from MyModelSwitch would have another shape.
What I propose then is a node having a definable callback on the model that returns the
"Class" of required shape. This callback selector might be stored within the
node, or might be a supposed shape DynamicProxyShape - which continually asks for the
shape from the model, and then draws that shape. With the model returning the
"Class" of a particular shape, then the coupling is that the model knows
"which shape" it wants drawn, but not "how" to draw it, which defined
as-a-kind-of-ROShape. I am not sure how that aligns with good OO design or not.
cheers, Ben
Alexandre Bergel wrote:
As Doru said, Roassal does not provide a way to
compose shapes. I will work on it soon, but right now you can't compose. One easy way
to render something that looks like what you have shown is to nest nodes:
view node: 'UML' forIt: [
view shape rectangle withText. view node: 'ROShape'.
view shape label text: [:el | el model selector].
view nodes: ROShape methods.
view verticalLineLayout
].
Soon we will have more...
Cheers,
Alexandre
On Jul 29, 2012, at 10:48 AM, Ben Coman <btc(a)openInWorld.com> wrote:
> Okay. What is the next best approach for what is available at the moment? Subclass
one of the other ROShapes... ?
>
> I noticed "ROElement>>addShape: " What is the philosophy/architecture
there? Reviewing all the senders shows that 90% only call #addShape: once. The only case
where #addShape: is called multiple times on an object it always looks like this...
> node
> addShape: ROBox new;
> addShape: ROBorder new.
>
> cheers, -ben
>
> Tudor Girba wrote:
>
>> Currently, there is no support for complex shapes. This is definitely a direction
in which we have to invest.
>>
>> Cheers,
>> Doru
>>
>>
>> On 28 Jul 2012, at 18:06, Ben Coman wrote:
>>
>>
>>
>>> Referring to the attached graph, what is the best way to approach the
following in Roassal.
>>> Currently with Mondrian I produce a produce a custom shape using the forms
builder in #mondrianShape, which is a method of my ModelRoot class. Referring to the
attached graph, as an example this shows the class name "Substation" above the
instance "SS1" and has a space for contained items to be displayed within it.
>>>
>>>
>>>
>>>>> mondrianShape
>>>>>
>>>>>
>>> | builder |
>>> builder := MOFormsBuilder new.
>>> builder column; center; fill; pref; grow.
>>> builder
>>> row; center; pref; fill; grow;
>>> row; center; pref; fill; grow;
>>> row; center; pref; fill; grow.
>>> builder x: 1 y: 1 add: ( MORectangleShape new text: #strippedClassName;
textAlignment: #left; borderColor: Color white ) .
>>> builder x: 1 y: 2 add: ( MORectangleShape new text: #localName;
textAlignment: #left ) .
>>> builder x: 1 y: 3 add: ( MORectangleShape new ) .
>>> builder x: 1 y: 3 add: ( MOChildrenShape new ) .
>>> ^builder shape
>>>
>>> In conjunction with the use of MOChildrenShape above, class ModelRoot also
has method #addSubViewTo: which descends through contained classes - for example instance
"primary" inside "T1" inside "SS2" inside "Figure
8..."
>>>
>>>
>>>
>>>>> addSubViewTo: aMOViewRenderer
>>>>>
>>>>>
>>> aMOViewRenderer
>>> node: self
>>> using: self mondrianShape
>>> forIt:
>>> [
>>> self children do:
>>> [ :child |
>>> child addSubViewTo: aMOViewRenderer.
>>> ]
>>> ]
>>>
>>> My initial issues in migrating this to Roassal are:
>>> 1. Roassal appears to not provide any methods that have "using:" in
them.
>>> 2. Roassal appears to not support MOFormsBuilder
>>>
>>> It may be that I am accessing to much internal methods. The code above was
the result of evolutionary hacking as I was learning Mondrian. I would be happy to
re-architect if someone can advise best practice for Roassal.
>>>
>>> cheers -ben
>>>
>>>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.