[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz ./TODO doc/pegboard/1018/PEG_1018.rst doc/u...
From: |
Asko Soukka |
Subject: |
[Gzz-commits] gzz ./TODO doc/pegboard/1018/PEG_1018.rst doc/u... |
Date: |
Tue, 10 Dec 2002 11:06:40 -0500 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Asko Soukka <address@hidden> 02/12/10 11:06:39
Modified files:
. : TODO
doc/pegboard/1018: PEG_1018.rst
Added files:
doc/uml : vanishingview.mp vanishingview.uml viewtool.mp
viewtool.uml
Removed files:
doc/pegboard/1017: PEG_1017.rst
Log message:
sketching ViewTool
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/TODO.diff?tr1=1.444&tr2=1.445&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1018/PEG_1018.rst.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/vanishingview.mp?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/vanishingview.uml?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/viewtool.mp?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/viewtool.uml?rev=1.1
Patches:
Index: gzz/TODO
diff -u gzz/TODO:1.444 gzz/TODO:1.445
--- gzz/TODO:1.444 Mon Dec 9 17:48:17 2002
+++ gzz/TODO Tue Dec 10 11:06:38 2002
@@ -190,25 +190,26 @@
+ speed up tests: currently too much execfile().. could
pre-compile and exec compiled in the same globals().
humppake:
- - If OvalBgVob is used as Bg vob it should not use colored
- sectors:
- - OvalBgVob to use colored stripes also with AWT
- - SectorVob for LollipopCV, 360dgrs is a CircleVob :)
- - SquareVob, square with colored sectors
- - should these be named ColoredXXXVob?
- - think about renderables for OpenGL sides, with them
- dicing and using with distorted coords would be possible :)
+ - write about representing mind map in ZZ
+ - how different dimensions would be used
+ - how n:m associations are handled
+ - rethink View interfaces
+ - PEG1018 - ViewTool
+ - peg about stretching and mounting connections
+ - rename solids into cellColors or something...
+ - Vobs
+ - ColoredSectorVob for LollipopCV, 360dgrs is a CircleVob :)
+ - ColoredSquareVob, square with colored sectors
+ - think, how "solids" could be rendered using renderables
+ in circular forms, specially stripes in oval could be
+ difficult
- opengl demo, which uses view (made in python)
- - rethink interfaces between PlainVanishing and VobScene
- eg. correct implementation of LollipopCellView needs
- to affect connections' coordsys (through box?)
- - first have to understand current interfaces -> UML
- - new PEG, new UMLs would be good
- - also stretching relates this
- - more about PEG1018 - generalizing VobVanishingClient
+ - new umltool and paper about it
- BallCellView (text inside the ball)
- we don't want more complicated line breaker, uses cell's
content will be in square
+ + create gfx/libirregu from irregu4.py and make effects.py to use
+ new libirregu... ask jvk for more.
+ fix the way nonlinearity of coordsys is handled.
Needs a slightly better approach, with also
direction of nonlinearity taken into account.
Index: gzz/doc/pegboard/1018/PEG_1018.rst
diff -u gzz/doc/pegboard/1018/PEG_1018.rst:1.3
gzz/doc/pegboard/1018/PEG_1018.rst:1.4
--- gzz/doc/pegboard/1018/PEG_1018.rst:1.3 Thu Nov 14 10:40:07 2002
+++ gzz/doc/pegboard/1018/PEG_1018.rst Tue Dec 10 11:06:39 2002
@@ -1,35 +1,107 @@
-=============================================================
-PEG 1018: Generalizing VobVanishingClient
-=============================================================
-
-:Author: Asko Soukka
-:Last-Modified: $Date: 2002/11/14 15:40:07 $
-:Revision: $Revision: 1.3 $
+==========================================================================
+PEG 1018: ViewTool (was generalizing VobVanishingClient)
+==========================================================================
+
+:Author: Asko Soukka, Benja Fallenstein
+:Date-created: 2002-12-10
+:Last-Modified: $Date: 2002/12/10 16:06:39 $
+:Revision: $Revision: 1.4 $
:Status: Incomplete
-Yes, I believe that the view interface in 0.8 is much more
-flexible than the on in 0.6. Although I had been working
-on 0.8 for weeks, I still had problems to get used to those
-coordsys transformations everywhere. I think there should be
-easy-to-use interface for prototyping new views. Something with
-you can start directly putting some vobs into space and see
-the results without need to think optimal view spesific
+This PEG is about creating a ViewTool. The ViewTool would offer easy-to-use
+interface for prototyping new views - and lowering the treshold of starting
+view development.
+
+PS. UML-diagrams are not currently compiled with this PEG, but
+by "make uml", sorry for that.
+
+Motivation
+----------
+
+Yes, I (*humppake*) believe that the view interface in GZZ 0.8 is much more
+flexible than the on in 0.6. Although, I worked on 0.8 for weeks, and I
+still had problems with our coordinate system biased approach for drawing.
+It's good, but feels too abstract at first sight, since you are used handle
+only one coordinate system at time.
+
+I think there should be easy-to-use interface for prototyping new views.
+Something with you can start directly by putting some vobs into the space
+and see the results without needing to think about optimal view spesific
coordinate systems first.
+Current VanishingClient
+-----------------------
+
+In view ``gzz.view.VobVanishingClient`` has been done a lot of work for
+abstracting some of the general things that view must do - and thus,
+made them easier to do.
+
+- method for placing all vobs using only one coordinate system
+ (without even need to know that other exists), using this was
+ familiar from GZZ 0.6
+- easy method for creating connections
+
+::
+
+ /** An interface abstracting some things away from the vanishing view.
+ */
+ public interface VanishingClient {
+ final int CENTER = 1;
+
+ Object getVobSize(Cell c, float fract, int flags, Dimension into);
+ void place(Cell c, Object o, float fract, int x0, int y0, int x1,
int y1,
+ int depth, float rot);
+
+ /** There should be a connection between the given cells.
+ * If one of the cells hasn't yet been placed, this means that
+ * a stub in that direction should be drawn.
+ */
+ void connect(Cell c1, Cell c2, int dx, int dy);
+ }
+
+.. image:: ../../uml/vanishingview.png
+
+Describing shortly (this will be replaced with sequence diagram):
VobVanishingClient
+implements both the View and VanishingClient interface. When its render() is
called,
+it will call PlainVanishing, where the views placing logic is handled.
PlainVanishing
+will then use VanishingClient's abstracted interface for placing cells.
+
Issues
------
-``VobVanishingClient`` seems to have already it own simplified
-routines for placing vobs and building connections. Using those in
-``PlainVanishing`` looks quite nice. So, generalizing ``VobVanishingClient``
-would be a good start. So, because ``PlainVanishing`` is a hard coded
-component int ``VobVanishingClient``, I would first make this component
-a parameter for ``VobVanishingClient``'s constructor, interface for the
-component, and finally ``PlainVanishing`` only implements that interface.
-Looks too simple this far. There must another issues to concern?
+- Should ViewTool hide the coordinate system biased approach like
+ VanishingClient currently does?
+
+ RESOLVED: Not. Learning the coordinate system approach is crucial
+ for view development. Though, coordinate system should be easy
+ to use.
+
+- How cells should be placed through ViewTool?
+
+ The drawing box, cell, its 2D coordinates, depth and
+ scale could be passed to ViewTool's place. It will return
+ an appropriate coordinate system for placing vob self by
+ VobScene's put().
+
+ - Do we need anymore to get and use Dimension size from VobScene,
+ when we are using box coordinate systems?
+
+- How connections should be created through ViewTool?
+
+- Do we need rasters in general?
+
+- If yes, what rasters should exactly do?
+
+- How rasters could be used through ViewTool?
+
+- Finally, would using planned methods make e.g. out basic
+ views look more clear?
+
+Changes
+-------
-Naming issues for above... and UML.
+This is currently in very beginning.
-Probably using the raster could also be made easier or at least
-better documented.
+.. image:: ../../uml/viewtool.png
+Finally basic views should rewrite using ViewTool.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz-commits] gzz ./TODO doc/pegboard/1018/PEG_1018.rst doc/u...,
Asko Soukka <=