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@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