21 Jul
2015
21 Jul
'15
11:52 p.m.
Hmm...
right now I have one burning question:
Why build a completely new layer of indirection with different API instead
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...
So, how do you tell builder that you want to color or add interaction to a
> "group" of nodes and not all the nodes
in the visu? Groups are first-class
> entities in Telescope. Composites are first class entities with
> customizable interactions.
>
> Roassal has RTGroup, which is obviously less powerful, but often enough.
Plus
the
"if node matches this add/change/do this" that is also implemented by
Telescope.
Moreover, the model takes care of updating only the
concerned nodes and
> not all of the visualization.
>
> Roassal updates only what should be updated, not the whole visualization.
(And
if some particular builder does rerender everything, that's the
builder's problem.) After all this is transitive --- if Telescope can do
partial changes and is on top of Roassal, so can Roassal do it...
The paper is not the best way to see what Telescope is
able to.
>>
>> Look at the demos and the presentation Anne did at Esug:
>> http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…
>>
>> I saw the presentation at ESUG but I wanted more insight (or
documentation)...
Anyway, I'll continue my exploration... but the idea that I might need
interaction between Telescope and Roassal elements and concepts doesn't
make me happy...
Peter
22 Jul
22 Jul
7:40 a.m.
On another note...
why no inspector support?
[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]
On Tue, Jul 21, 2015 at 11:52 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hmm...
right now I have one burning question:
Why build a completely new layer of indirection with different API instead
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...
So, how do you tell builder that you want to color or add interaction to a
> "group" of nodes and not all the
nodes in the visu? Groups are first-class
> entities in Telescope. Composites are first class entities with
> customizable interactions.
>
> Roassal has RTGroup, which is obviously less powerful, but often enough.
Plus
the
"if node matches this add/change/do this" that is also implemented by
Telescope.
Moreover, the model takes care of updating only
the concerned nodes and
> not all of the visualization.
>
> Roassal updates only what should be updated, not the whole
visualization. (And
if some particular builder does rerender everything,
that's the builder's problem.) After all this is transitive --- if
Telescope can do partial changes and is on top of Roassal, so can Roassal
do it...
The paper is not the best way to see what
Telescope is able to.
>>
>> Look at the demos and the presentation Anne did at Esug:
>> http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…
>>
>> I saw the presentation at ESUG but I wanted more insight (or
documentation)...
Anyway, I'll continue my exploration... but the idea that I might need
interaction between Telescope and Roassal elements and concepts doesn't
make me happy...
Peter
7:51 a.m.
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).
Peter
On Wed, Jul 22, 2015 at 7:40 AM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
On another note...
why no inspector support?
[[[
TLVisualization>>gtInspectorVisualizationIn: aComposite
<gtInspectorPresentationOrder: -1>
self generate.
aComposite roassal2
title: 'Visualization';
initializeView: [ self generator view ]
]]]
On Tue, Jul 21, 2015 at 11:52 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
Hmm...
right now I have one burning question:
Why build a completely new layer of indirection with different API
instead 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...
So, how do you tell builder that you want to color or add interaction to
> a "group" of nodes and not all the
nodes in the visu? Groups are
> first-class entities in Telescope. Composites are first class entities with
> customizable interactions.
>
> Roassal has RTGroup, which is obviously less powerful, but often
enough. Plus
the
"if node matches this add/change/do this" that is also implemented by
Telescope.
Moreover, the model takes care of updating only
the concerned nodes and
> not all of the visualization.
>
> Roassal updates only what should be updated, not the whole
visualization. (And
if some particular builder does rerender everything,
that's the builder's problem.) After all this is transitive --- if
Telescope can do partial changes and is on top of Roassal, so can Roassal
do it...
The paper is not the best way to see what
Telescope is able to.
>>
>> Look at the demos and the presentation Anne did at Esug:
>> http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…
>>
>> I saw the presentation at ESUG but I wanted more insight (or
documentation)...
Anyway, I'll continue my exploration... but the idea that I might need
interaction between Telescope and Roassal elements and concepts doesn't
make me happy...
Peter
10:05 a.m.
2015-07-22 7:40 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
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.
A good idea would be to have some examples data with each visualization
On Tue, Jul 21, 2015 at 11:52 PM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
--
*Guillaume Larcheveque*
Hmm...
right now I have one burning question:
Why build a completely new layer of indirection with different API
instead 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...
So, how do you tell builder that you want to color or add interaction to
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> a "group" of nodes and not all the
nodes in the visu? Groups are
> first-class entities in Telescope. Composites are first class entities with
> customizable interactions.
>
> Roassal has RTGroup, which is obviously less powerful, but often
enough. Plus
the
"if node matches this add/change/do this" that is also implemented by
Telescope.
Moreover, the model takes care of updating only
the concerned nodes and
> not all of the visualization.
>
> Roassal updates only what should be updated, not the whole
visualization. (And
if some particular builder does rerender everything,
that's the builder's problem.) After all this is transitive --- if
Telescope can do partial changes and is on top of Roassal, so can Roassal
do it...
The paper is not the best way to see what
Telescope is able to.
>>
>> Look at the demos and the presentation Anne did at Esug:
>> http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…
>>
>> I saw the presentation at ESUG but I wanted more insight (or
documentation)...
Anyway, I'll continue my exploration... but the idea that I might need
interaction between Telescope and Roassal elements and concepts doesn't
make me happy...
Peter
12:19 p.m.
On Wed, Jul 22, 2015 at 10:05 AM, Guillaume Larcheveque <
guillaume.larcheveque(a)gmail.com> wrote:
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.
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.
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?
Thanks,
Peter
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.
Why build a completely new layer of indirection with different API instead
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.
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
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*
10:03 a.m.
2015-07-21 23:52 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
Yes but Telescope does it for you...
--
*Guillaume Larcheveque*
Hmm...
right now I have one burning question:
Why build a completely new layer of indirection with different API instead
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
So, how do you tell builder that you want to color or add interaction to a
Because we are creating really interactives visualizations we were always
out limit of RTGroup
> "group" of nodes and not all the
nodes in the visu? Groups are first-class
> entities in Telescope. Composites are first class entities with
> customizable interactions.
>
> Roassal has RTGroup, which is obviously less powerful, but often enough.
Plus
the
"if node matches this add/change/do this" that is also implemented by
Telescope.
Moreover, the model takes care of updating only
the concerned nodes and
> not all of the visualization.
>
> Roassal updates only what should be updated, not the whole
visualization. (And
if some particular builder does rerender everything,
that's the builder's problem.) After all this is transitive --- if
Telescope can do partial changes and is on top of Roassal, so can Roassal
do it...
The paper is not the best way to see what
Telescope is able to.
>>
>> Look at the demos and the presentation Anne did at Esug:
>> http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…
>>
>> I saw the presentation at ESUG but I wanted more insight (or
documentation)...
Anyway, I'll continue my exploration... but the idea that I might need
interaction between Telescope and Roassal elements and concepts doesn't
make me happy...
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
25 Jul
25 Jul
12:41 p.m.
Peter
telescope idea is that you can define visualization (model) where you can
define advanced behavior and reuse it.
We presented last year the model to alex and this year again and
he saw that there is a real added value.
Scripts does not let us reuse and build more complex model.
Telescope has a visualziation model (not a canvas on which you write)
+ composite + advanced interaction.
telescope model should be taken and used in future version of Roassal.
We do not take it personally if alex takes synectique's code/ideas.
For us we will continue to build around and if telescope is fusioned
into Roassal 3
then even better.
I dream about
Roassal 3 = Bloc + Telescope + some part of Roassal 2 (layout....)
And roassal 3 does not have to be compatible to Roassal2. And people do
not have
to migrate to Roassal 3.
Stef
2:28 p.m.
Hi Stef,
I do understand (at least partially) the value behind it and I tried to
play with it more, and there were things that I really liked...
However I feel like many of those concepts should've been introduced
directly as part (or an extension) of Roassal, instead of top of it,
because that seriously limits its (re)usability without fully committing to
Telescope.
In any case from my experiments and considering all other things (like
serious lack of documentation, even smaller user-base, different API, ...),
I think that it would be currently too much work for too little added value
for me,
because I already had to solve some of the problems you guys had on my own,
so I would be basically spend a lot of time rewriting code and at the end I
would be where I started... and then Roassal 3 would come and I would have
to rewrite again.
Also another important part is the overall user experience, so this
definitely means that I will need to dive deep into Roassal (and even
Morphic) to make things work (as I've already done and continue to do). And
since you decided that you want yet another layer between Telescope and
Roassal (to be able have another rendering libraries (although from the
Telescope code I've seen it's not exactly separated)).
So this would mean for me that I would have to write a lot of stuff twice
(or three times (Roassal+Telescope+adapter)); and again, with little added
benefit for me (and since I'm not payed for what I do; what I want is my
primary concern).
So to summarize...
I think that currently best scenario is to postpone it and look at it again
when Roassal 3 starts rolling around, because I will be migrating to
Roassal 3 for sure also because of Bloc.
This will also give me more time to familiarize myself more with Telescope
and make the transition less painful.
Peter
On Sat, Jul 25, 2015 at 12:41 PM, stepharo <stepharo(a)free.fr> wrote:
Peter
telescope idea is that you can define visualization (model) where you can
define advanced behavior and reuse it.
We presented last year the model to alex and this year again and
he saw that there is a real added value.
Scripts does not let us reuse and build more complex model.
Telescope has a visualziation model (not a canvas on which you write)
+ composite + advanced interaction.
telescope model should be taken and used in future version of Roassal.
We do not take it personally if alex takes synectique's code/ideas.
For us we will continue to build around and if telescope is fusioned into
Roassal 3
then even better.
I dream about
Roassal 3 = Bloc + Telescope + some part of Roassal 2 (layout....)
And roassal 3 does not have to be compatible to Roassal2. And people do
not have
to migrate to Roassal 3.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3544
days inactive
3548
days old
8 comments
3 participants
participants (3)
-
Guillaume Larcheveque -
Peter Uhnák -
stepharo