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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
> 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: >> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by abergel
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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by abergel
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |