20 Jul
2015
20 Jul
'15
6:58 p.m.
Hi Alex,
I forgot to ask at ESUG... but what are the plans for moving towards
Roassal3 and Bloc?
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.
Thanks,
Peter
20 Jul
20 Jul
9:13 p.m.
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.
Yeah, Telescope code is a bit obscur time to time.
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.
Well… The goal of Roassal 3 is to embrace Bloc and all the good things it brings, which
includes fancy events, OSWindow and other rather technical but important points (eg.,
supercool event handlers). In addition the GT team is helping Alain, which is somehow a
quality label for me.
Alex told me that during the next two months Bloc may be severely changed.
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.
If you are ready to invest now in Bloc, then you are very welcome! Widgets are missing I
believe. What are you plans now?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
9:23 p.m.
Well… The goal of Roassal 3 is to embrace Bloc and all the good things it
brings, which includes fancy events, OSWindow and other rather technical
but important points (eg., supercool event handlers). In addition the GT
team is helping Alain, which is somehow a quality label for me.
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?
Alex told me that during the next two months Bloc may be severely changed.
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
9:51 p.m.
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?
Yes, Bloc will replace Trachel. But since Bloc has more than Trachel, Roassal will be
slightly (positively) impacted.
So this would mean that work on Roassal3 will start
in two+ months?
Maybe earlier. I started to work on it actually. I already have something that runs
actually :-)
Cheers,
Alexandre
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
10:42 p.m.
Hi Peter,
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.
You should take the last version (
https://ci.inria.fr/moose/job/Telescope/lastSuccessfulBuild/artifact/Telesc…)
and look at the TLDemos class methods to have examples of the way to create
or use Telescope visualization.
If your problem is about visualization but not yet managed by Telescope;
ask me and I will look at it.
The Telescope philosophy is to provide a stable API with a smart model that
ease the life of the user; that's why we prefer to implement less things
but have them well designed.
Cheers,
2015-07-20 18:58 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
Hi Alex,
I forgot to ask at ESUG... but what are the plans for moving towards
Roassal3 and Bloc?
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.
Thanks,
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
*Guillaume Larcheveque*
21 Jul
21 Jul
1:55 a.m.
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.
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;
ask me and I will look at it.
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
8:50 a.m.
the paper you mention was written very quickly and might not be that
much helpful
At some point we will try to write something better
Don't hesitate to come back to us with questions
nicolas
On 21/07/2015 01:55, Peter Uhnák wrote:
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.
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; ask me and I will look at it.
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
9:44 a.m.
Hi Peter,
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…
2015-07-21 1:55 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
I don't know exactly what are your problems but if it is to create really
--
*Guillaume Larcheveque*
high level visualizations with lot of
interactivity, Telescope is
definitely the good tool to use.
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;
ask me and I will look at it.
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
10:17 a.m.
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…
<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. 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
On 21 Jul 2015, at 09:44, Guillaume Larcheveque
<guillaume.larcheveque(a)gmail.com> wrote:
Hi Peter,
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…
<http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example>
2015-07-21 1:55 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com
<mailto:i.uhnak@gmail.com>>:
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.
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; ask me and I
will look at it.
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 <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
--
Guillaume Larcheveque
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:28 a.m.
Writing visualization that are stateless is indeed harder. Yuriy, you said it well.
The paper is here:
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Builder/020…
Alexandre
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 21 Jul 2015, at 09:44, Guillaume Larcheveque
<guillaume.larcheveque(a)gmail.com> wrote:
Hi Peter,
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…
2015-07-21 1:55 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
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.
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; ask me and I
will look at it.
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
--
Guillaume Larcheveque
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
11:11 a.m.
Hi,
On Tue, 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.
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….
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
On 21 Jul 2015, at 09:44, Guillaume Larcheveque <
guillaume.larcheveque(a)gmail.com> wrote:
Hi Peter,
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…
2015-07-21 1:55 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
I don't know exactly what are your problems but if it is to create really
--
*Guillaume Larcheveque*
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
high level visualizations with lot of
interactivity, Telescope is
definitely the good tool to use.
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;
ask me and I will look at it.
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
11:40 a.m.
I’m not saying that Telescope does not have cool features that are not available in
Roassal. What I say is that I believe that builder is made to ease people lives and the
natural evolution of builder are Telescope Visualizations. Some people my not agree with
me, but I think that it’s strange that Roassal builders didn’t move that way, and as there
are already this cool features in Telescope they are not integrated into Roassal.
Uko
On 21 Jul 2015, at 11:11, Usman Bhatti
<usman.bhatti(a)gmail.com> wrote:
Hi,
On Tue, Jul 21, 2015 at 10:17 AM, Yuriy Tymchuk <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
On 21 Jul 2015, at 09:44, Guillaume Larcheveque
<guillaume.larcheveque(a)gmail.com <mailto:guillaume.larcheveque@gmail.com>>
wrote:
Hi Peter,
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…
<http://www.slideshare.net/GuillaumeLarcheveque/telescope-introduction-and-example>
2015-07-21 1:55 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com
<mailto:i.uhnak@gmail.com>>:
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.
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; ask me and I
will look at it.
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 <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
--
Guillaume Larcheveque
_______________________________________________
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>
_______________________________________________
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>
11:46 a.m.
On Tue, Jul 21, 2015 at 11:40 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>
wrote:
I’m not saying that Telescope does not have cool
features that are not
available in Roassal. What I say is that I believe that builder is made to
ease people lives and the natural evolution of builder are Telescope
Visualizations.
The we are on the same page :)
Some people my not agree with me, but I think that
it’s strange that
Roassal builders didn’t move that way, and as there are already this cool
features in Telescope they are not integrated into Roassal.
I know Roassal team is thinking about it :)
Uko
On 21 Jul 2015, at 11:11, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
Hi,
On Tue, 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.
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….
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
On 21 Jul 2015, at 09:44, Guillaume Larcheveque <
guillaume.larcheveque(a)gmail.com> wrote:
Hi Peter,
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…
2015-07-21 1:55 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
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
--
*Guillaume Larcheveque*
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
really high level visualizations with lot of
interactivity, Telescope is
definitely the good tool to use.
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;
ask me and I will look at it.
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
3201
days inactive
3202
days old
12 comments
6 participants
participants (6)
-
Alexandre Bergel -
Guillaume Larcheveque -
Nicolas Anquetil -
Peter Uhnák -
Usman Bhatti -
Yuriy Tymchuk