Re: [Gzz] OrthoCoordsys???, reverting

[Tuomas Lukka]

> >Based on all this discussion, I'm beginning to think that we may
> >not reach a conclusion soon enough for release - 
> >
> >Benja, would you mind a lot if I asked you to revert the hierarchical
> >coordsys change and put it in lava/ or something?
> 
> Yes, I would. Please, don't.

Ok, I won't.

> However, that feeling is still fragile. This became very clear to me 
> when you said the above today-- I felt like running into a wall, 
> stopping all forward movement instantly. Yes, I understand that if we 
> put it into lava/ now, we can develop it there until GL can handle it to 
> and then put it back... but that doesn't help: having to maintain the 
> old stuff seems so heavy a burden that I'm afraid I'd lose faith again, 
> and I don't want that now.

For me, the worst feeling has been that I've had no thorough understanding
of what really happens inside, with the horrible *Space stuff that used
to be in there.

This API change, to me, represented a step back to that era, which is
partly why I reacted so strongly to it.

> The actual approach for hierarchical coordsys we take isn't that 
> important (as long as it is able to express the things we currently use 
> it for: cell padding, and skewing cell content so that the insertion 
> cursor is always visible). 

Ahem... that's not all. Hierarchical coordsys are also needed for Pp,
which currently does them using Viewport vobs which is not at all as nice.
And for PP, we do want rotation and anisotropic scaling.

That would also be another reason for my strong reaction: Pp and the
fact that you're not so excited about it.

That's why it would have been nice to discuss the assumptions used
for the design prior to implementation ;)

> I may disagree with you on what the cleanest 
> way to implement this is, but as always, you're making the final 
> decision there and it's ok if we disagree. But please, let's not move 
> *backward*. I think it should be possible to find *some* way to 
> implement this in GL quickly for now... we can always change it later.

Ok, I'll try to find a way to do that, but with the understanding
that this is still a temporary system; when starting to continue the UML
docs, we need to give this area a really thorough overview and 
look at the requirements, assumptions, limitations and come up 
with the design.

Sound ok?

Hmmm... it might be as easy as just making one intermediate call
to ask the coorder to make a hierarchical coordsys clipped to a particular
one...

        Tuomas