3 Jan
2013
3 Jan
'13
9:20 a.m.
Ben Coman wrote:
This is a post in two parts. The first is purely
Rossal and the second
is on the Glamour-Roassal integration.
Part One
RODraggableWithVelocity seems to have a problem overshooting the drag
distance with large numbers of elements. For example, referring to the
next script, with RODraggable only, if I drag the view background
sideways by a quarter-window-width, even though it takes a few seconds
to respond to a drag, the final position of the elements is a
quarter-window-width sideways. However with RODraggableWithVelocity,
doing the same action, I observe the elements briefly appear a
quarter-window-width sideways, then another quarter-window-width, then
another until the elements disappear off the side of the window. This
behaviour disappears from this example by reducing to 1000 elements,
but occurs in my application with only 100 elements (plus an equal
number of edges).
-----
| rawView domain |
rawView := ROView new @ RODraggable " @ RODraggableWithVelocity " .
domain := 1 to: 10000.
domain do: [ :x | rawView add: (ROElement on: x) + (ROLabel) ].
ROVerticalLineLayout on: rawView elements.
rawView open
----
Part Two
Given that the paintingBlock of the GLMRoassalPresentation returned by
'GLMCompositePResentation>>rossal'
is passed a ROMondrianViewBuilder that has already added
RODraggableWithVelocity to the rawView, how do I remove that
RODraggableWithVelocity from the rawView? The '@' method seems to
work differently between ROView (in processing the interaction
straight away) and ROElement (which seems to store the interaction for
later processing so it can be removed more easily).
In addition, could something like a GLMMorphicRoassalRawRenderer be
added to the Glamour-Roassal interface? - which would pass an
unencumbered ROView to the paintingBlock. It is not really a
Glamour-Roassal interface at the moment, more of a Glamour-Mondrian
interface. I hacked up a GLMMorphicRoassalRawRenderer as best I could
as part of my experiment with "Interactive Roassal" but it wasn't very
elegant and I'm not sure it was correct.
cheers -ben
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Alternatively, perhaps the existing infrastructure could be made to work
with
browser transmit to: #graphic andShow: [ :a |
a roassal
view: ROView new ;
title: 'Roassal Diagram' ;
painting:
[ :view :transmittedselection | ..etc..
The view: message here would override the default value set by the #view
method...
^view ifNil: [view := ROMondrianViewBuilder new]
I notice that GLMRoassalPresentation>>renderOn: has a flag 'This should
be the responsibility of the view'.
This method was one that I copied and modified for my
GLMRoassalRawPresentation removing calls to #applyLayout and
#populateMenuOn since they errored with ROView replacing
ROMondrianViewBuilder. Perhaps these lines might be pushed into a method
of ROMondrianViewBuilder, so the same method of ROView could be empty.
For my GLMMorphicRoassalRawRenderer>>render: I copied from
GLMMorphicRoassalRenderer
changing the line...
myMorph := ROMorph on: view stack
to...
myMorph := ROMorph on: view
so perhaps that could also be pushed into a method on both ROView and
ROMondrianViewBuilder.
GLMMorphicRoassalRenderer>>actOnPresentationUpdate would need similar
attention since it has ROMondrianViewBuilder hardcoded (except I never
got a chance debug this for ROView, since the 'self halt' I inserted in
it never got activated)
Anyway, that is enough to chew on (and the limit of my grasp of the
overall architecture of the Glamour-Roassal interface).
cheers -ben