19 Jul
2012
19 Jul
'12
10:33 p.m.
Hi!
I've just found this video:
http://cel.inf.usi.ch/index.php?action=gallery
I am not sure I really want to program a tetris that way, but the tool they have is
interesting. It intensively use zooming in and out. When you zoom in, you see different
objects and when you zoom out they disappear or they change their visual representation.
For Roassal, we are thinking about adding new graphical elements when a particular height
of the camera is reached. The elements will then disappear when the camera is getting
altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario
for a better mechanism?
Is there anything else you guys want to see in this zooming ability?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
19 Jul
19 Jul
11:03 p.m.
I think it has an obvious application in software architecture
visualization.
It's called drill down and people like it.
You select a dependency between two packages.
The you zoom in (drill down) and you see the two classes that are
actually in dependency.
Drill down, you see the method invocation and the 2 methods
Drill further down, you see the actual instruction in the calling method
[drill down even more and you see the bit code of the compiled method ?
;-) ]
One could also use it to navigate in the code:
Take a variable declaration, zoom in it's type and you open the class
declaration, zoom in the class and you see it's components, ...
May be it is not so much a good idea here, because zooming in makes you
going up and down abstraction levels (from variable to class, to its
components, to an other class, ...)
I'd better go to sleep
nicolas
On 19/07/12 22:33, Alexandre Bergel wrote:
Hi!
I've just found this video:
http://cel.inf.usi.ch/index.php?action=gallery
I am not sure I really want to program a tetris that way, but the tool they have is
interesting. It intensively use zooming in and out. When you zoom in, you see different
objects and when you zoom out they disappear or they change their visual representation.
For Roassal, we are thinking about adding new graphical elements when a particular height
of the camera is reached. The elements will then disappear when the camera is getting
altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario
for a better mechanism?
Is there anything else you guys want to see in this zooming ability?
Cheers,
Alexandre
11:27 p.m.
You select a dependency between two packages.
The you zoom in (drill down) and you see the two classes that are actually in
dependency.
Drill down, you see the method invocation and the 2 methods
Drill further down, you see the actual instruction in the calling method
[drill down even more and you see the bit code of the compiled method ? ;-) ]
Should this recursion be infinite?
Once I have the method invocation and I continue zooming, is the class still getting
bigger (because you are zooming).
On some point, the camera will simply reach the surface you are currently zooming in.
An easy way to circumvent this issue, is to have have a stack of views. Views get
activated under certain condition of the camera of another view.
In Roassal, each view has a camera. Another solution, is to have a camera per graphical
element.
One could also use it to navigate in the code:
Take a variable declaration, zoom in it's type and you open the class declaration,
zoom in the class and you see it's components, ...
May be it is not so much a good idea here, because zooming in makes you going up and down
abstraction levels (from variable to class, to its components, to an other class, ...)
Maybe in that case you want to have a "hot frame" (I do not remember the name)
that Doru's proposed for Glamour. Press Cmd - space and you get a window that shows
you an inspector.
Looking at the source code is a very frequent operation, you probably do not want to
constantly zoom in and out.
Cheers,
Alexandre
I'd better go to sleep
nicolas
On 19/07/12 22:33, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I've just found this video:
http://cel.inf.usi.ch/index.php?action=gallery
I am not sure I really want to program a tetris that way, but the tool they have is
interesting. It intensively use zooming in and out. When you zoom in, you see different
objects and when you zoom out they disappear or they change their visual representation.
For Roassal, we are thinking about adding new graphical elements when a particular height
of the camera is reached. The elements will then disappear when the camera is getting
altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario
for a better mechanism?
Is there anything else you guys want to see in this zooming ability?
Cheers,
Alexandre
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
22 Jul
22 Jul
10:04 a.m.
New subject: [Pharo-project] Brain storming request: Semantic zooming for Roassal
Zooming is interesting and since Athens canvas is opening the vectorial space we should
definitively
try. I have serious doubt that this can of modeling will go anyway. It may be a fun master
or bachelor topics.
Now I would like to be able to build the same with Pharo:
clean event
nice support for zoom
and we are getting closer and closer.
Stef
On Jul 19, 2012, at 10:33 PM, Alexandre Bergel wrote:
Hi!
I've just found this video:
http://cel.inf.usi.ch/index.php?action=gallery
I am not sure I really want to program a tetris that way, but the tool they have is
interesting. It intensively use zooming in and out. When you zoom in, you see different
objects and when you zoom out they disappear or they change their visual representation.
For Roassal, we are thinking about adding new graphical elements when a particular height
of the camera is reached. The elements will then disappear when the camera is getting
altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario
for a better mechanism?
Is there anything else you guys want to see in this zooming ability?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
25 Jul
25 Jul
4:40 p.m.
Hi Alex!
That is a cool idea.
Views get activated under certain condition of the
camera of another view.
This is what semantic zooming really is about! If I have a figure for a
software package and I only have a 5 by 5 pixel area to draw on, I will
render it empty. If I have 50 by 50 I can draw classes. If I have 500 by
500 I can draw methods and classes. So I am not sure I understand how your
camera altitude will implement this, but having a "condition" for selecting
one rendering or the other of a given GUI element seems the right way to
go. In fact the easiest way of letting the client of the framework
implement his own semantic zooming is by letting him register a callback
for when the available area for a figure changes. Then he could choose one
or the other of his available renderings. A variant in which the framework
would know a little more would have the client pass pairs of surface
thresholds and renderers to the framework.
Cheers,
M.
11:31 p.m.
Thanks Mircea
We will soon release it
Alexandre
On Jul 25, 2012, at 10:40 AM, Mircea Filip Lungu wrote:
Hi Alex!
That is a cool idea.
Views get activated under certain condition of the camera of another view.
This is what semantic zooming really is about! If I have a figure for a software package
and I only have a 5 by 5 pixel area to draw on, I will render it empty. If I have 50 by 50
I can draw classes. If I have 500 by 500 I can draw methods and classes. So I am not sure
I understand how your camera altitude will implement this, but having a
"condition" for selecting one rendering or the other of a given GUI element
seems the right way to go. In fact the easiest way of letting the client of the framework
implement his own semantic zooming is by letting him register a callback for when the
available area for a figure changes. Then he could choose one or the other of his
available renderings. A variant in which the framework would know a little more would have
the client pass pairs of surface thresholds and renderers to the framework.
Cheers,
M.
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
4311
days inactive
4317
days old
5 comments
4 participants
participants (4)
-
Alexandre Bergel -
Mircea Filip Lungu -
Nicolas Anquetil -
Stéphane Ducasse