47 |
(Tjl:) I didn't make my point clear. We *can* do this, |
(Tjl:) I didn't make my point clear. We *can* do this, |
48 |
if we ask, at vobscene construction time, |
if we ask, at vobscene construction time, |
49 |
how tall a given cs will be. |
how tall a given cs will be. |
50 |
|
|
51 |
|
(Benja:) Ah. Now I understand somewhat... However, |
52 |
|
even then, you cannot satisfy scaling in two dimensions, |
53 |
|
so it would have to be ``scale(int into, float scale)``. |
54 |
|
Also, you're talking about the "height" of a coordsys-- |
55 |
|
what is this? Coordsys are, at this point, transformations |
56 |
|
of points-- so what's the "height" of a transformation? |
57 |
|
Finally, I still don't like scale being here, because |
58 |
|
generally having to know the scale before the view |
59 |
|
comes in means that we cannot switch to a system where |
60 |
|
(in gl) we determine the parent transformations |
61 |
|
*after* the views have done their job. For example in |
62 |
|
text layout, it would be nice if we could first render |
63 |
|
the text with a given width, then look at the resulting |
64 |
|
height and decide how to translate the result-- this |
65 |
|
requires that a coordsys gets its parent after it |
66 |
|
is first created-- not currently allowed, but not |
67 |
|
impossible to change. |
68 |
|
|
69 |
|
|
70 |
And into AffineVobCoorder the following functions:: |
And into AffineVobCoorder the following functions:: |
71 |
|
|
73 |
int scale(int into, float x, float y, float z); |
int scale(int into, float x, float y, float z); |
74 |
|
|
75 |
Also, for all these functions, we should have a shorthand |
Also, for all these functions, we should have a shorthand |
76 |
in VobScene: |
in VobScene:: |
77 |
|
|
78 |
public int translateCS(int into, Object key, float x, float y); |
public int translateCS(int into, Object key, float x, float y); |
79 |
|
|