22 Jul
2015
22 Jul
'15
2:29 p.m.
2015-07-22 12:19 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
On Wed, Jul 22, 2015 at 10:05 AM, Guillaume Larcheveque <
guillaume.larcheveque(a)gmail.com> wrote:
At this point you are not sure that data were introduced, I can do
TLButterfly new inspect and then it will not work because I didn't put
datas in my visu so generate will fail. In addition it's not a good idea to
generate the visualization without the user approval especially if he is
debugging an infinite loop for example ;-)
2015-07-22 7:40 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
What do you mean? The datas were introduced to the object already, this is
same like calling "visualization open". Or maybe I am treating TL scripts
too much like Roassal scripts with different API.
On another note...
why no inspector support?
[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]
Because you cannot just open a Visualization like that; it requires some
datas.
Why build a completely new layer of indirection with different API instead
I do understand this but that's not what I am asking. Why not create it
alongside Roassal2 instead of on top of it; or just create a better
Mondrian? What I am trying to understand is what is the benefit of
introducing a whole new level of indirection just to simplify one thing,
instead of improving the underlying layer in the first place. Because I
feel that I am loosing a lot of power because Roassal is hidden from me.
Because Roassal2 was creating a whole new model (RTGroup instead of
RoGroup)... Obviously you are losing some power because Telescope is not a
drawing framework nor Roassal functionnalities copy, just a visualization
framework and Roassal is just used as a renderer (the goal of the connector
is to create easily new ways to render our model; in Bloc or html5 for
example). We faced lots of difficulties when using roassal as a
visualization framework especially with interactions that modify the model
and so created a model specialized for that, that offers much more than
just "simplifying one thing"; just try to create with roassal the demo
#exampleMovingNodeToAnotherGroup and you will understand that many things
are impacted.
Scripting philosophy was also problematic for us because we have to
maintain lots of visualizations and observe that we were copying/pasting
lots of code that was complicated to keep up to date. The abstraction of
Action/Interaction composition was really reward-full with composite nodes
especially.
of
improving and extending Roassal (=Telescope alongside Roassal instead of
on top of it)? It seems like a lot of effort went into creating it while it
would have had bigger and better impact in Roassal...
Because we created Telescope when we had to move from Roassal to Roassal2
and at this time Roassal2 was not supporting a Mondrian like syntax so we
tried to create an equivalent powerful syntax than Mondrian with an object
oriented approach And this got overlooked probably (relates to the
question above):
So there is TLStyleSheet>>compositeExpandedByDefault:
But what if I want for example to have the option to manually resize
something? Roassal gives me RTResizeable. Would I have to write some
special TLInteraction or can I somehow reuse what Roassal offers? This also
applies for Roassal interactions in general.
compositeExpandedByDefault is not about resizing; it is about showing
children of a composite node. Resizing is just a side effect because
currently Telescope make some room for that (maybe a better strategy would
be to create smaller elements for children and not resize parent). If you
want to resize something, just change style with TLStyleCustomizationAction.
And even for Roassal in general... e.g.
RTShape allSubclasses size. "30"
TLSimpleShape allSubclasses size. "3"
So if I wanted to use some other shape from Roassal (for example box with
rounded corners), would I have to create matching TL shape and then define
mapping in the generator/connector?
In my opinion, rounded corners are not another kinds of shapes, just a
customization of existing and so should be a style attribute. Yes you can
create your own subclasses of TLShape but Telescope is not designed to just
make easier to use Roassal but to offer a bigger level of abstraction.
Telescope is not about thinking in term of drawing but in term of
visualization model.
Thanks,
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
*Guillaume Larcheveque*