Because currently I am very hesitant in engaging with Telescope which may or may not solve some of my problems... but the code is really, really hard to read for me.

So from this perspective it might be more fruitful for me to spend energy on Bloc, provided there will be some more gradual movement from 2 to 3.

My understanding was that this would basically replace Trachel layer or so? So if I wanted to have some nice shapes and visual objects I could compose them in Bloc? Or am I mistaken?

So this would mean that work on Roassal3 will start in two+ months?

In any case, Roassal3 should remain largely compatible with Roassal2. The API will be roughly the same, so migrating code should be rather pretty straightforward. I don't think that this is either possible nor welcome, because if Bloc introduces different ways to use events and such, you would have to create an extra layer just to hide Bloc... but will see how this will evolve. Peter _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I don't know exactly what are your problems but if it is to create really high level visualizations with lot of interactivity, Telescope is definitely the good tool to use.

ask me and I will look at it.

I don't know exactly what are your problems but if it is to create really That was my understanding so I wanted to look at it. But without any documentation it was hard for me to even begin. Usman Bhatti posted in another thread link to a Telescope paper, so I'll read it tomorrow and hopefully it will give me a little bit of insight. If your problem is about visualization but not yet managed by Telescope; Well we have already heavily invested in Roassal and this is not going to change, since we are continuing to work even on quite low level stuff (like bendable lines, elements resizing, attach points, ...). But I wanted to see, if Telescope could help us with some high-level abstractions, which are currently quite painful for us. I even started implementing some Eclipse GEF ideas... So I'll read the paper and I'll see... Peter _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Jul 21, 2015, at 10:17 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: Just my 2cents: As far as I understand one of the main features of Telescope are “Visualizations” that essentially are models that you set up and then they spit out a view on demand. Now builders in Roassal were designed to be the same. Here is the first page of agile visualization book, that is about builders and was first written as an IWST paper that was not accepted: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e…. It tells that there is a #renderIn: method that should be overwritten by a builder developer and which accepts and view and does what the builder should do. Now some time after this documentation was written, people started develop “stateless” builders that don’t collect all data but instead instantly draw something. I started to complain about this already at that time… Now as I see a situation now is that Telescope is a part of Roassal that Roassal voluntarily refused to be. From my point of view the only reason to do this stateless builders is because they are easier to implement, you don’t have to create single building method and so on. Otherwise they are much harder to use because you have to remember order. Uko _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 21 Jul 2015, at 11:11, Usman Bhatti &lt;usman.bhatti(a)gmail.com&gt; wrote: Hi, On Tue, Jul 21, 2015 at 10:17 AM, Yuriy Tymchuk &lt;yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: Just my 2cents: As far as I understand one of the main features of Telescope are “Visualizations” that essentially are models that you set up and then they spit out a view on demand. Now builders in Roassal were designed to be the same. 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. Here is the first page of agile visualization book, that is about builders and was first written as an IWST paper that was not accepted: http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-e… <http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example>. It tells that there is a #renderIn: method that should be overwritten by a builder developer and which accepts and view and does what the builder should do. Now some time after this documentation was written, people started develop “stateless” builders that don’t collect all data but instead instantly draw something. What is the stateless builder because the paper does not mention it or may be I missed something? If it is about parameterizing the visu, then telescope offers this mechanism with the help of blocks and selectors and the visualization is therefore disconnected from a particular usage. Moreover, the model takes care of updating only the concerned nodes and not all of the visualization. I started to complain about this already at that time… Now as I see a situation now is that Telescope is a part of Roassal that Roassal voluntarily refused to be. Telescope was conceived to write reusable visualizations and it wasn't destined to replace Roassal from the beginning. But there are some interesting concepts in Telescope that you might see taken up in Roassal 3. Telescope should be seen as high-level composable model for a visualization and we have created visualizations that are highly interactive. We have done things like showing connections amongst several levels (e.g. packages, classes, methods) and it wasn't too difficult to do with a clean model and composite shapes with interactions. Telescope is a rich model for visualization and it does not replace the rendering features of Roassal (at least not for now). regards. usman From my point of view the only reason to do this stateless builders is because they are easier to implement, you don’t have to create single building method and so on. Otherwise they are much harder to use because you have to remember order. Uko _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev <https://www.iam.unibe.ch/mailman/listinfo/moose-dev>