fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fenfire-dev] Mudyc merge request


From: Tuomas Lukka
Subject: Re: [Fenfire-dev] Mudyc merge request
Date: Tue, 7 Oct 2003 08:27:53 +0300
User-agent: Mutt/1.5.4i

On Tue, Oct 07, 2003 at 08:15:23AM +0300, Matti Katila wrote:
> On Mon, 6 Oct 2003, Tuomas Lukka wrote:
> >     +++ mod/include/vob/vobs/Trivial.hxx
> >     @@ -300,6 +300,39 @@
> > 
> >      VOB_DEFINED(TransTest);
> > 
> >      +
> >      +/** A Vob to draw a selection with 3 'selection modes'.
> >      + * 2nd coordinate system is used to select the current mode.
> >      + * The mode is represented by a vob. These 3 possibile 'selection 
> > mode'
> >      + * vobs are set in parameters.
> >      + * <p>
> >      + * Modes(2nd cs square size width):
> >      + *    <=1 normal,
> >      + *    <= 2 pre selection and
> >      + *    other is post selection.
> >      + */
> > 
> > This is not good: the selectVob is a far more general tool,
> 
> "A vob which has three vobs and one of these three are rendered depending 
> of the first coordinate system parameters." better?

Much, *MUCH* better. I'd slightly change the language:

        A vob which gets three vobs as parameters and, at rendering time,
        chooses one of these to render based on the first coordinate system
        box size.

but what you wrote is already 90% there. Of course, you have to also
describe how the box size chooses it.

> If it's general, there must be possibility to give n vobs with variable 
> size of cs parameters.

Yes, that would be good. Passing a Vob[] would be nice.

> > you are now talking about a single application. 
> > The javadoc should not mention anything like
> > pre selection, post selection except as an *example* of how it can be used.
> 
> This is native code.

I really don't understand what that has to do with it?

> > Also, why is t0 the one to be passed to the vobs and t1 the condition?
> 
> curry is good, yes.

What?

> > What kind of a name is "FocusWithBuoysManager"? It doesn't tell me anything.
> 
> You haven't ever asked what does the BuoyViewMainNode or BuoyViewNodeType
> tell me =)  

Implicitly yes: if there's a name that's non-obvious, you should mail to the 
list.
My choices of names and my code are - *MUST* BE - at least as open to criticism
as anyone else's. 

> So, after reading half an hour for BuoyView prefix it started 
> to make sense and I took the [Multi]BuoyManager name to please more 
> other developers ;)

Ok

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]