fenfire-dev
[Top][All Lists]
Advanced

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

Re: [Fenfire-dev] Mudyc's merge request


From: Matti Katila
Subject: Re: [Fenfire-dev] Mudyc's merge request
Date: Mon, 3 Nov 2003 08:22:32 +0200 (EET)

On Sat, 1 Nov 2003, Tuomas Lukka wrote:
> Extensions: why not use a map in python for which extensions
> are enabled - a static "if" statement is not as fun. 
> Also, this should probably be in the main FenPDF object
> 
> So:
> 
>       def useExtension(self, extname):
>               return self.extensions.get(extname, 0)

I'll fix this soon.
 
> ParallelView2D:
> 
>       /** Array of parallel View2D intances enclapsed
>        *  to one View2D. The first item in array is
>        *  the most meaningful, i.e., it determines the size
>        *  and it is first asked to return a child view2d.
>        *  The simple idea of parallelism is to have only
>        *  one instance of no meaningful View2D instances
>        *  by sharing them for different views.
>        */
> 
> Number one: "ParallelView2D" is an unclear name.
> How about "View2DDecorator" or "View2DList".
> 
> What is this class used for? Explaining that as an example
> would be a great step forward in the javadoc.
> 
> Overriding the javadocs of the methods in View2D may or may
> not be good.

View2DList it'will be. I try to think an example for it.


> "PlaneContent"?
> 
> We were discussing this piece of architecture but I really
> don't think this interface and implementation are a good idea.
> What I meant is that AbstractMainNode should have an extra
> variable, 

I don't think that this is very easy to implement since we keep jumping 
from mainnode to another one. I will try to add argument contentView to 
AbstractMainNode's constructor.

> 
>       /** The View2D that is the logical "content" of
>        * the plane rendered by this MainNode.
>        */
>       View2D planeContentView2D;
> 
> and (with corresponding javadocs)
> 
>       View2D getPlaneContentView()
> 
> Making an extra object that still uses the "getChildView" trick
> to get the view isn't IMHO a good solution.

>       --- orig/org/fenfire/fenpdf/actions/eventgrabs.py
>       +++ mod/org/fenfire/fenpdf/actions/eventgrabs.py
>       @@ -136,6 +137,12 @@
>                self.createFlyingNode(vs, self.node, self.ev, self.fenPDF)
>                self.drewMainNode = mainNode
> 
>       +        viewFunction = 
> self.fenPDF.views.getMultiplexerNodeContentFunction()
>       +        placeable = viewFunction.f(self.fenPDF.fen.graph, self.tipNode)
>       +        cs = vs.orthoBoxCS(0, 'TipNode', -1000,50,50, 1,1,
>       +                           placeable.getWidth(), placeable.getHeight())
>       +        placeable.place(vs, cs)
>       +
> 
> What in the world does that do? I have no idea what a tipnode is. Could you
> add some comment explaining what this is.

With text cloud you will see the final content as a 'tip' (neuvo, vaari, 
ohjeistus?) in the left-up corner. I try to document it better ,)


   -Matti





reply via email to

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