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-ex...
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
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@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-ex...
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
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@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@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-ex...
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
2015-07-22 7:40 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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@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-ex...
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, Jul 22, 2015 at 10:05 AM, Guillaume Larcheveque < guillaume.larcheveque@gmail.com> wrote:
2015-07-22 7:40 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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.
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
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
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 12:19 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
On Wed, Jul 22, 2015 at 10:05 AM, Guillaume Larcheveque < guillaume.larcheveque@gmail.com> wrote:
2015-07-22 7:40 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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.
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.
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 ;-)
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
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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2015-07-21 23:52 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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
"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.
Because we are creating really interactives visualizations we were always out limit of RTGroup
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...
Yes but Telescope does it for you...
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-ex...
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Guillaume Larcheveque -
Peter Uhnák -
stepharo