1 |
============================================================= |
========================================================================== |
2 |
PEG 1018: Generalizing VobVanishingClient |
PEG 1018: ViewTool (was generalizing VobVanishingClient) |
3 |
============================================================= |
========================================================================== |
4 |
|
|
5 |
:Author: Asko Soukka |
:Author: Asko Soukka, Benja Fallenstein |
6 |
|
:Date-created: 2002-12-10 |
7 |
:Last-Modified: $Date$ |
:Last-Modified: $Date$ |
8 |
:Revision: $Revision$ |
:Revision: $Revision$ |
9 |
:Status: Incomplete |
:Status: Incomplete |
10 |
|
|
11 |
Yes, I believe that the view interface in 0.8 is much more |
This PEG is about creating a ViewTool. The ViewTool would offer easy-to-use |
12 |
flexible than the on in 0.6. Although I had been working |
interface for prototyping new views - and lowering the treshold of starting |
13 |
on 0.8 for weeks, I still had problems to get used to those |
view development. |
14 |
coordsys transformations everywhere. I think there should be |
|
15 |
easy-to-use interface for prototyping new views. Something with |
PS. UML-diagrams are not currently compiled with this PEG, but |
16 |
you can start directly putting some vobs into space and see |
by "make uml", sorry for that. |
17 |
the results without need to think optimal view spesific |
|
18 |
|
Motivation |
19 |
|
---------- |
20 |
|
|
21 |
|
Yes, I (*humppake*) believe that the view interface in GZZ 0.8 is much more |
22 |
|
flexible than the on in 0.6. Although, I worked on 0.8 for weeks, and I |
23 |
|
still had problems with our coordinate system biased approach for drawing. |
24 |
|
It's good, but feels too abstract at first sight, since you are used handle |
25 |
|
only one coordinate system at time. |
26 |
|
|
27 |
|
I think there should be easy-to-use interface for prototyping new views. |
28 |
|
Something with you can start directly by putting some vobs into the space |
29 |
|
and see the results without needing to think about optimal view spesific |
30 |
coordinate systems first. |
coordinate systems first. |
31 |
|
|
32 |
|
Current VanishingClient |
33 |
|
----------------------- |
34 |
|
|
35 |
|
In view ``gzz.view.VobVanishingClient`` has been done a lot of work for |
36 |
|
abstracting some of the general things that view must do - and thus, |
37 |
|
made them easier to do. |
38 |
|
|
39 |
|
- method for placing all vobs using only one coordinate system |
40 |
|
(without even need to know that other exists), using this was |
41 |
|
familiar from GZZ 0.6 |
42 |
|
- easy method for creating connections |
43 |
|
|
44 |
|
:: |
45 |
|
|
46 |
|
/** An interface abstracting some things away from the vanishing view. |
47 |
|
*/ |
48 |
|
public interface VanishingClient { |
49 |
|
final int CENTER = 1; |
50 |
|
|
51 |
|
Object getVobSize(Cell c, float fract, int flags, Dimension into); |
52 |
|
void place(Cell c, Object o, float fract, int x0, int y0, int x1, int y1, |
53 |
|
int depth, float rot); |
54 |
|
|
55 |
|
/** There should be a connection between the given cells. |
56 |
|
* If one of the cells hasn't yet been placed, this means that |
57 |
|
* a stub in that direction should be drawn. |
58 |
|
*/ |
59 |
|
void connect(Cell c1, Cell c2, int dx, int dy); |
60 |
|
} |
61 |
|
|
62 |
|
.. image:: ../../uml/vanishingview.png |
63 |
|
|
64 |
|
Describing shortly (this will be replaced with sequence diagram): VobVanishingClient |
65 |
|
implements both the View and VanishingClient interface. When its render() is called, |
66 |
|
it will call PlainVanishing, where the views placing logic is handled. PlainVanishing |
67 |
|
will then use VanishingClient's abstracted interface for placing cells. |
68 |
|
|
69 |
Issues |
Issues |
70 |
------ |
------ |
71 |
|
|
72 |
``VobVanishingClient`` seems to have already it own simplified |
- Should ViewTool hide the coordinate system biased approach like |
73 |
routines for placing vobs and building connections. Using those in |
VanishingClient currently does? |
74 |
``PlainVanishing`` looks quite nice. So, generalizing ``VobVanishingClient`` |
|
75 |
would be a good start. So, because ``PlainVanishing`` is a hard coded |
RESOLVED: Not. Learning the coordinate system approach is crucial |
76 |
component int ``VobVanishingClient``, I would first make this component |
for view development. Though, coordinate system should be easy |
77 |
a parameter for ``VobVanishingClient``'s constructor, interface for the |
to use. |
78 |
component, and finally ``PlainVanishing`` only implements that interface. |
|
79 |
Looks too simple this far. There must another issues to concern? |
- How cells should be placed through ViewTool? |
80 |
|
|
81 |
|
The drawing box, cell, its 2D coordinates, depth and |
82 |
|
scale could be passed to ViewTool's place. It will return |
83 |
|
an appropriate coordinate system for placing vob self by |
84 |
|
VobScene's put(). |
85 |
|
|
86 |
|
- Do we need anymore to get and use Dimension size from VobScene, |
87 |
|
when we are using box coordinate systems? |
88 |
|
|
89 |
|
- How connections should be created through ViewTool? |
90 |
|
|
91 |
|
- Do we need rasters in general? |
92 |
|
|
93 |
|
- If yes, what rasters should exactly do? |
94 |
|
|
95 |
|
- How rasters could be used through ViewTool? |
96 |
|
|
97 |
|
- Finally, would using planned methods make e.g. out basic |
98 |
|
views look more clear? |
99 |
|
|
100 |
|
Changes |
101 |
|
------- |
102 |
|
|
103 |
Naming issues for above... and UML. |
This is currently in very beginning. |
104 |
|
|
105 |
Probably using the raster could also be made easier or at least |
.. image:: ../../uml/viewtool.png |
|
better documented. |
|
106 |
|
|
107 |
|
Finally basic views should rewrite using ViewTool. |