26 Sep
2012
26 Sep
'12
11:57 p.m.
Indeed, you can work around the current issue with two
nodes. But, I
think this goes against a clean model.
Ideally, one model object should appear once in the graph and be shown
with one shape. Whether a shape is simple or complex, it is another
issue. This is why we need a more elaborate way of defining shapes.
I agree with you. I have been working on this issue for a couple of days already. We are
making progress, but more work is necessary.
So far, shapes form a linked list. I have recently added a translating shape to give an
offset (dx@dy) to a part of the shape chain.
In my opinion, translating shape is an interesting way to compose shapes. We can easily
think about how to design a MOFormsBuilder using this mechanism.
However, I have a growing negative feeling: each operation such as #elementAt: (used to
get children element) and #contains: (whether a point is within the bounds of an element)
needs to crawl over this list of shapes. As you can imagine the drawback: the last version
of Roassal is slower than the version of last week. Sure, I can add caches to speed these
operations up, but we will fall into a dangerous situation in which caches have been
introduced to make Roassal work, instead of addressing particular scalability problems.
Now, I cannot stop thinking about subclassing ROElement into a ROCompositeElement.
Does this mail make sense?
Cheers,
Alexandre
On Wed, Sep 26, 2012 at 8:51 PM, Ben Coman <btc(a)openinworld.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Vanessa Peña Araya wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 09/26/2012 03:09 PM, Ben Coman wrote:
If you remove the outer border, then that may be just what is required.
Doing this layout at the element level like this seems easier, but not so
flexible as with shapes. Now for my additional benefit, how would you do
that raw Roassal. That is, by removing ROMondrianViewBuilder from the
example.
cheers -ben
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Depending on Dennis' requirements, the problem with using two elements is
that when node '1' is moved, node 'test' does not move with it.
Guessing from what I can see of the Roassal architecture, it seems shapes
are meant for this purpose to remain in a fixed orientation its element. The
difficulty however with putting a label at the bottom is that the height of
the ChildrenShape is dynamic depending on how you drag around the inner
nodes.
With recent changes I had requested regarding shapes, I envisage
something like the following would work, and you can see the label
positioned correctly but the mouse interaction to drag 'inner2' is not quite
right yet, or I'm doing it wrong:
-----------------
| view outer inner1 inner2 childrenShape labelOffsetShape |
outer := ((ROElement spriteOn: 'outer') + ROLabel ).
inner1 := ((ROElement bare on: 'SN-TestData') @ RODraggable @
ROLightlyHighlightable ). "shapes defined later"
inner2 := ((ROElement spriteOn: 'inner2' ) + ROLabel @
ROLightlyHighlightable ).
childrenShape := ROChildrenShape new.
labelOffsetShape := ROTranslatingShape offset:
[ :el2 | | offset |
offset := 0 @ (childrenShape boundsFor: el2) extent y negated.
Transcript crShow: offset asString, ' ', el2 model asString.
offset
].
inner1 + ROBorder + childrenShape + labelOffsetShape + ROLabel.
view := (ROView new @ RODraggable) add: (outer add: (inner1 add:
inner2)).
view open.
------------------
_______________________________________________
Actually you can with something like this:
| view rawView nodes node label |
rawView := ROView new.
view := ROMondrianViewBuilder view: rawView.
view shape rectangle.
nodes := view node: 'example' forIt:[
view interaction forwarder.
view shape rectangle size: 100.
view node: 1.
view interaction forwarder.
view shape label.
view node: 'test'.
view verticalLineLayout.
].
view noLayout.
view open.
In which the interactions to the nodes are "forwarder" to the parent. But
yes, the solution with ROTranslatingShape seems nicer :)
Cheers,
Vanessa.