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

[Tuomas Lukka]

Hey, this is a GREAT mail - please try to keep these kinds of 
questions coming. I never realized there were so many docbugs...

Thank you SO much for writing down these questions! This is
really valuable for us.

Can you put the fixes from this mail into the docs? I'm really
busy before wednesday

        Tuomas

On Mon, Apr 14, 2003 at 10:52:30AM +0300, Matti Katila wrote:
> > 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.

Ok, just put an entry in my journal.

> > 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?

Umm, where's that code? The comment is wrong: should be


        // create a new coordinate system, at (100,100), scaled 
        // by 100 in x-direction and 50 in y-direction.

> 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. 

Yes, it is so: in the inside coordinat system, that's the box.

> Should be said if this 
> is one of the overall design priorities or not. 

What is, exactly?

>  - - 
> 
> > 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 
Because activate() doesn't think about anything being topmost.

Actually, probably the best alternative would be to rename

        getCSAt

into

        getTopmostActiveCSAt

?


> + something technical specs(whose ancestor, what direct, what nearest, 
> '*'?).
> 
> Why topmost, why not bottom? 

That's what's rendered on top.

> how to get activated coords between topmost 
> and bottom? 

Hmm, yes, good idea would be to PEG the previous name change
and also at the same time the new method

        getAllActiveCSAt

Can you do that?

>   Issue: what should be activated in vobs? nodes content? why/why not? 
> This can be solved by nodeview with one state adding.

Yes?

> x,y?? are they screen coordinates? 

Yes.

> If this is all about coordinate system 
> why not specify the context with x and y?

What context? I'm not understanding you now. What context?

> > public final int translateCS(int into, ...
> 
> What we translate? 

We create a new coordinate system in into() which is 
just a translated version of it.

> How does boxCS affect to this?

Translate makes the box a unit square.

> If we have recursive coords how it affects?

???

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

Yes. 

> > scaleCS
> 
> It scales, ok. What is the point to scale to?

Around origin.

> At least I want to lock one point with the to be scaled coords if I 
> want to scale. Is it center?

The origin.

> > 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? 

It allows skewing and rotation, i.e. a general 2D affine transformation
and Z translation. 

Ortho has the new x coordinate depend only on the old X coordinate,
here it can depend both on the old X and Y coordinates.

> > 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?

This is old crud - should probably PEG to remove it,
at least deprecate it.

> > rotateCS(int into, java.lang.Object key, float degrees) 
> 
> What's the point where rotating is done to? center or left up? other?

Origin.

> > unitSqCS(int into, java.lang.Object key) 
> 
> What's this? Unit Square something? 

This makes a coordinate system such that its unit square
goes orthogonally to the parent's box.

I.e. if parent's box is (40,20)
then (.5,.5) in the new coordsys maps to (20,10).

It's basically a scale() which takes its parameters from the parent.

> > 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. 

Couldn't agree more.

> The basic parts are quite stable already.

Yes.

> 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? 

Yes, it's pretty obvious that some vital calls are missing.
But that's why it's important to develop libvob in connection
with our other projects: the input from fenfire and pp is 
what drives it to the right direction.

> 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.

Yes, that says definitely that work is needed.

> Also it's important that we have one deterministic implementation of 
> libvob (expect rotation and so in awt/gl). 

You mean the parts that haven't been made to work in both yet.
Yes, this is true.

> 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. 

What port?

Hmm, you seem to have really good questions and ideas here:
would you mind writing the release requirements for release 0.1,
including the above (AWT-GL compatibility&c).

Then we could start working towards that goal coherently.

Again, thanks for this - you're doing a great job!

        Tuomas