fenfire-dev
[Top][All Lists]
Advanced

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

Re: [Fenfire-dev] CLI


From: Matti Katila
Subject: Re: [Fenfire-dev] CLI
Date: Mon, 2 Aug 2004 20:21:02 +0300 (EEST)

On Thu, 22 Jul 2004, Benja Fallenstein wrote:
> Hi,
> thanks for the comments!

Hi, you are welcome :)

Comments come a bit late, though..

> Matti Katila wrote:
>> Once you implement a one it would be nice to see a working demo "max. 100 
>> lines" to get to know with the architechture and perhaps help with other 
>> missing lobs.
> Do you mean a component in 100 lines, or an application using lobs in 
> 100 lines?

Those demo applications that use lobs.

>> I'm interesting in the mouse events in generally. Could you say some words 
> A side-effect is that you can't play some tricks with the lob system: if 
> you draw outside the area you're supposed to draw in, you won't get 
> mouse events there.

Yes, with coordinate systems that wouldn't be a problem of course.


>> That's interesting because that way 
>> coordinate systems don't need to be activated as I have understood. That's 
>> also much more faster than iterating all coordinate systems trough which 
>> has been a bottle neck. 
> 
> Yes, but of course it won't work for Loom and similar things -- there we 
> still need to have the vobscene involved, because otherwise the "loom 
> view lob" would have to remember where it rendered which node, which 
> would be stupid. And of course iterating through all coordinate systems 
> can in theory be optimized in a similar way, it's just work I guess :-)

With loom there has not been use cases where the problem would occur. The 
problem is easy to see when dragging nodes on canvases in fenpdf. There 
the mouse events are handled few too many times, for example
-whether a buoy click
-which main viewport
-is it node?
-which letter of a node
and so on... if every check takes 20ms it comes close to noticeable delay.

In loom you get needed information with one shot, i.e., cs and node. 
And usually scene changes after click - there's no drag like events.


About "special view lob", like loom view lob. I think we need to have a 
system like X offers. A window like viewports from where buoys float 
around and connections between different items of differnet viewports can 
be made. This all should be made so that different viewport managers 
could be used. Simple one would be original double viewport manager found 
in fenpdf but later we could have more advanced, like the one you like to 
use, was it ion? 

I think buoys and link making ability explains why we can't use current 
systems provided by X.

 
> I hope you like the general Lob approach :-)

I can not say yet .-) I don't think there are many right(tm) ways to 
implement one :-) It looks promising.

At least your way to start working with it was better because you just 
did it ;)

>>>>nor use libvob as fast as it could use it? 
>>>How so?
>> Like with scrollbar, you don't want to wait new scene when you scroll.
>> That is, scrolling should adjust some coordinate system parameters (or 
> 
> Ok. Well, yes and no: It's true that you don't want to re-generate the 
> scene when dragging the scrollbar. However, dragging doesn't even work 
> yet... but if it did, we wouldn't have the infrastructure yet to just 
> change the existing scene rather than re-generating the scene.

Yes, and we need the infrastructure on some day :)


   -Matti








reply via email to

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