[Fenfire-dev] Re: back tomorrow

[Matti Katila]

Moi!

On Tue, 22 Feb 2005, Benja Fallenstein wrote:
> The thing is that when designing this, I was thinking we would have
> separate Fentwine and Canvas views -- now we have them integrated at
> the code level the way they are conceptually, which is great!!! -- ;-)
> -- and so the design has to change.
> 
> I think perhaps we should have a hierarchy of cursors, so that when an
> upper-level cursor changes, the lower-level cursor is discarded, but
> when a lower-level cursor changes, the upper-level cursor isn't
> affected. Like this:
> 
> level 1 -- fentwine cursor
> level 2 -- canvasview cursor
> level 3 -- text cursor
> 
> *scratches head*

Something similar. I was thinking that since we have structure and spatial 
view divided into own parts should we just have a own cursor for both?

There are cases, however, when that would not make sense. For example 
assume a canvas spatial view and you have just made into it by browsing 
from left or right. By rotating you can change the rotation of current 
node and the structure it has but if you go away from the node, like 
panning the canvas, what should happen to rotation?

If rotation should go back to zero (or half?) then we need to create a new 
cursor but if not, we should have different structure cursor for each 
node.

> Sorry, I'm not fully following here, but would the scheme proposed
> above address this? I.e.,
> 
>     Map canvasContentCache;
>     Map nodeLobCache;
> 
>     Lob getMainLob(Model cursor) {
>         canvasContent = (Lob)canvasContentCache.get(getCanvas(cursor));
>         if(canvasContent == null) makeCanvasContent;
>         Lob l = new PanzoomLob(canvasContent);
>         return l; // don't cache
>     }

Why shouldn't these lobs be cached?

The naming sounds a bit vague to me: node and main. It might be, for 
example with calendar spatial view, that there is no node available with 
current date and time in calendar cursor. So it sounds a bit too 
"fentwine" to call that nodeLob if node is nothing.

How about base(ment) or ground lob instead of main?
I might propose spatialContent instead of node lob but it's vague too.


>     Lob getNodeLob(Object node) {
>         if(nodeLobCache.containsKey(node)) return (Lob)nodeLobCache.get(node);
> 
>         canvasContent = (Lob)canvasContentCache.get(getCanvas(node));
>         if(canvasContent == null) makeCanvasContent;
>         Lob l = new PanzoomLob(canvasContent);
>         nodeLobCache.put(node, l); // do cache
>         return l;
>     }

Ah, now I understood what you are thinking with these. A different lob 
returning method for buoys and main thing. Do *not* do that. As we design 
it there is just the structure and spatial views. The spatial views are 
not divided into buoy/node and main thing.

And this explains that you don't probably understand anything from above 
so should I try to explain the problem once a more?

We may have the same spatial view in different places in the screen. 
That's easy just create a triple of A --structLink--> A. For simple nodes 
it is not hard since they can not have different panning. But for canvases 
this is not the case. We are likely to have different panning for all the  
canvases. But we still can cache the content of A as a lob. We just need a 
different basement lob or coordinate lob to change the zooming and panning.

> > This is important because I would like all views in the Fenfire to be at
> > least zoomable.
> Explain? :-)

The spatial views should be ones that may be zoomed out or in (perhaps 
even the simple one). We know the problem with current web - everyone is 
using own size for fonts in their web pages. That is silly. Depending of 
my awake up time I may use smaller or larger fonts but I really hate that 
I need to change the font size per site.


   -Matti