Vob System (was: Re: [Gzz] Vob test failure)

[Matti Katila]

On Sat, 12 Apr 2003, Tuomas Lukka wrote:
>On Thu, Apr 10, 2003 at 10:39:07PM +0300, Matti Katila wrote:
>> On Thu, 10 Apr 2003, Tuomas Lukka wrote:
>>> I'm getting a bizarre failure:
>>> 
>>> ======================================================================
>>> FAIL: testActiveDepthWithTrans (__main__.Vobcoorder)
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>>   File "<string>", line 57, in testActiveDepthWithTrans
>>>   File "test/vob/api/vobcoorder.test", line 95, in testActiveDepthWithTrans
>>>     failUnlessEqual(cs3, c.getCSAt(0, s.width/2, s.height/2, None))
>>>   File "testutil", line 10, in failUnlessEqual
>>>   File "unittest.py", line 273, in failUnlessEqual
>>> AssertionError: 3 != 1
>>> ----------------------------------------------------------------------
>>> Ran 20 tests in 24.785s
>>> Has someone forgotten to run tests after committing?
>> 
>> No it's there because I think it does not work but don't know how to fix 
>> it or is it really broken.
>> 
>> btw. someone should document the vob system. it's still magic at least 
>> for me and the code seems to be cryptic also - the code doesn't explain 
>> itself, sorry ;-/
> 
> Umm, everyone: please be more specific when asking something like this.
> *WHAT* about it is the cryptic part, and what's the priorities? 
> 
> The basic model? The code generation?

Maybe both but I'm currently more interested in the basic model.

> Once you know what you want, just add it to my journal.

Replying now:

[random cut&paste, hopefully I don't break the context]

> // create a new coordinate system, at (100,100), with size (100,50).
> int cs = vs.coords.ortho(0, 0, 100, 100, 100, 50);

So, what's orthoBoxCS?

I think it's better to think left up is (0,0) and right down is (1,1) 
because the size should not been fixed in any kind. Should be said if this 
is one of the overall design priorities or not. 

 - - 

> activate(int cs) 
>     Cause the given coordinate system to be considered when getCSAt() is 
>      called.

> getCSAt
>     Get the topmost activated coordsys at (x,y), whose nearest activated 
>      * direct ancestor (not determining) is parent.

activate says something about getCSAt but getCSAt documentation doesn't 
match - why activate hasn't been documented to say anything about topmost 
+ something technical specs(whose ancestor, what direct, what nearest, 
'*'?).

Why topmost, why not bottom? how to get activated coords between topmost 
and bottom? I'm now in problems with pp if I should or not peg this kind 
system to libvob because I need it but also it's doable without it.
  Issue: what should be activated in vobs? nodes content? why/why not? 
This can be solved by nodeview with one state adding.

x,y?? are they screen coordinates? If this is all about coordinate system 
why not specify the context with x and y?

> public final int translateCS(int into, ...

What we translate? How does boxCS affect to this?
If we have recursive coords how it affects?

Ok this is explained in the overall documentation but should also be 
documented in methods.

> scaleCS

It scales, ok. What is the point to scale to?
At least I want to lock one point with the to be scaled coords if I 
want to scale. Is it center?

> affineCS(int into, java.lang.Object key, float depth, float cx, float 
> cy, float x_x, float x_y, float y_x, float y_y)

Lots of arguments with no meaning! Bad naming?

What this does vs. ortho? 

> put(Vob v, int d, int x, int y, int w, int h) 

x,y,w,h?  is this really needed? why we have coord systems if we have 
this?

> rotateCS(int into, java.lang.Object key, float degrees) 

What's the point where rotating is done to? center or left up? other?

> unitSqCS(int into, java.lang.Object key) 

What's this? Unit Square something? 


> But only *very* specifically - better to tell me more about what you want
> than is needed than less.

The Libvob is one of the most important bricks of our building so I think 
it should be more documented. The basic parts are quite stable already.
Otoh, I think something is broken if I can't make pp easily with it(read, 
knowing(hrmm. ;) too much about libvob). Doesn't it implicies that 
libvob isn't ready even for basic programs, does it? And gzz's pp is a 
hack. It's too easy to brake it by makeing simple modification to any 
coordinate systems and event handling stops working.

Also it's important that we have one deterministic implementation of 
libvob (expect rotation and so in awt/gl). If something isn't implemented 
throw error or such a thing, don't make "this works if we assume..." 
kludge. It's also important to inform the one who's responsibility is the 
port by mail or journal. 


   -Matti