fenfire-dev
[Top][All Lists]
Advanced

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

[Fenfire-dev] Re: back tomorrow


From: Benja Fallenstein
Subject: [Fenfire-dev] Re: back tomorrow
Date: Tue, 22 Feb 2005 15:36:47 +0100

On Tue, 22 Feb 2005 09:39:26 +0200 (EET), Matti Katila
<address@hidden> wrote:
> 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.

I think that they are different enough on the code lelvel that it's
just nonsense to use the same method for both.

- For buoys we ask, "render node N in its spatial context." For
mainviews we say, "here's a Model containing a Cursor. give me a lob
that renders the current state of the model, and possibly updates the
VobScene when the Model changes." -- I think it's *really* backwards,
when the StructureView wants to render a node, to create a "new
ObjectModel(new Cursor.SimpleCursor(node))" and then cache that so
that we don't create too many objects.

- We can cache the buoy lobs by node, but not the mainviews, because
they may not *have* a focused node, just an x/y translation on a
canvas. (We can cache the canvas content in both cases.)

- Also, the mainview sizing would have a nicer solution this way; the
mainview lob can have a different size request from the node lob.

- And we may actually want to render the mainview slightly
differently, because there we have more room. Not sure about this, but
we could e.g. include something like scrollbars.

> And this explains that you don't probably understand anything from above

True :)

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

Not exactly. We don't have links to canvases at all at the moment. We
have links to nodes *on* canvases.

If A is a node on a canvas, then A --structLink--> A means that the
same view is shown twice on the screen, true. But then the two
instances have the *same* panning.

On the other hand, if A and B are on the same canvas, then A
--structLink--> B means that different views of the same canvas are
shown on the screen. The lobs returned by my proposed getNodeLob() are
different, although they internally use the same lob to render the
canvas contents.

All this assumes that A and B are shown as buoys, not in the mainview.
In the mainview, we can be showing a cursor position that's just some
x/y position on the canvas. That's yet another case. The mainview lob
uses the same lob to render the canvas contents, but the panzoom is
determined by the current CanvasCursor, whereas for buoys the panzoom
is determined by the position of the node A (or B) on the canvas.

Note that when rendering a buoy, you don't have a separate cursor
position. The panzoom is fully determined by the node that is shown by
the buoy.

> We are likely to have different panning for all the
> canvases.

No, we have *one* panning for every node-on-a-canvas (A, B), and *one*
additional panning for the canvas shown by the mainview. All buoys
showing node A have the same panning, and all buoys showing node B
have the same panning.

(I mean, all buoys created by getNodeLob(A) or getLob(new
ObjectModel(new Cursor.SimpleCursor(A)), if you prefer. Of course in
such a buoy B can also be visible, if it is very close to A...)

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

Yes, except that you mean "the content of the canvas that A is on,"
because we do not show the canvas node itself in a special way at this
time.

My proposal does exactly this by having a canvasContentCache used by
both getMainLob() and getNodeLob(), and then additionally caching the
panzoom of getNodeLob(). Quoting myself :-)

   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
   }

   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;
   }

If I still don't understand, I'm sorry, please explain again.

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

So you think we should have one global setting for spatial view zoom?

- Benja




reply via email to

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