Re: [Fenfire-dev] CLI

[Benja Fallenstein]

Hi,

thanks for the comments!

Matti Katila wrote:
> On Sun, 18 Jul 2004, Benja Fallenstein wrote:
> > - Build everything from very simple primitives, like 'rectangle,' 
> > 'filled rectangle' or 'text vob.' I.e., don't have complex objects like 
> > RectBgVob as primitives; instead, build them up from simple primitive 
> > components. This comes from Fresco/InterViews.
>
> This may be advantage of code reuse but also produce longer code because 
> more objects must be constructed?

Not really, because you can still have a RectBgLob (we have one of sorts 
at the moment, which is called "Frame"[*]), but instead of being a 
primitive, it's built up from other primitives. RectBgVob is 228 lines, 
about 200 without the boilerplate, Frame is 68[**], about 40 without the 
boilerplate. Any code that uses Frame isn't longer than if it used 
RectBgVob.

Of course that's not counting the code in RectVob, FilledRectVob, 
ClipLob, and Between, all of which are used by Frame. But the point is 
that each of these has other uses, and if they weren't primitives, the 
code in them would have to be duplicated in those other places. The code 
reuse *does* make the code shorter, overall. :-)

[*] It's a bit more flexible than RectBgVob, having options for "how 
much of a margin is used" and "should the content be clipped or not?" 
Actually that's why I'm not sure it's here to stay, because all the 
options make code using it hard to read: "new Frame(lightColor, 
darkColor, 1, 0, true, true, false)" for example.

[**] 77 in the version in Arch, but I've just removed a couple of 
(currently) unused lines ;-)

> I don't think this is problem or 
> anything as long as them don't slow down the scene.

I haven't seen problems, but of course the demo so far has been 
small-scale. If there are problems later, we'll have to think about it.

> > I want the lob system to include a set of components, i.e. buttons, 
> > scrollbars, text fields etc., which are themeable.
>
> This themeability may somehow break the architechture. Be sure to keep 
> those small and simple lobs and collection type lobs separated. 

The important thing is to keep the themeable and the non-themeable lobs 
separate, and I agree that it is important. With the non-themeable lobs, 
the programmer knows exactly what will be shown on the screen when they 
use them; with the themeable lobs, the intent is "draw me a button, I 
don't care about the details, just use the current theme."

> > > Currently there seems to be some code for editor like app. It looks 
> > > interesting :)  How about menus, lists, checkboxes, buttons, 
> >
> > Menus, lists, checkboxes and buttons are planned features that I simply 
> > haven't implemented yet.
>
> 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?

If component, surely a button or a checkbox would provide the easiest 
example.

Re helping, sure that's appreciated, but I have to warn you that how 
things work might still change a lot. I'm still figuring the 
architecture out, because it doesn't do everything it should yet, and 
any feature to be added may make it necessary to refactor things :)

> I'm interesting in the mouse events in generally. Could you say some words 
> about it as well? How lob system handles those? The upper lob seems to 
> delegate the event to "bottom" lobs.

Yes, that's correct. When a lob that has children gets a mouse event, it 
figures out which child is hit by the event, and calls the event 
handling method of that child. It's basically the same way that mouse 
events propagate in AWT etc.

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. I've just figured that out because I'm implementing 
menus, and when you click on an item in the menu bar, you want to open a 
drop-down menu, and if you make the menu bar render that drop-down menu 
(as a lob), then the drop-down menu doesn't get click events because 
it's outside the area of the menu bar. So I can't play the trick here, I 
have to figure out an architecurally reasonable way to open a pop-up ;-)

> 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 :-)

> Like I said I have though PUI layer before but I didn't start to build 
> the system mainly because of I couldn't find good enough way to handle 
> those mouse inputs :)

I hope you like the general Lob approach :-)

> In fenpdf we used to hande all mouse events very separately and that was 
> a mess. I would like just to bind events to proper handlers

I'm not sure how you want the handlers to work. With the lob system, the 
idea is that you can wrap each lob in an event handler lob that will 
process mouse events in some way you like. (I.e., you pass it some 
object to call when the lob is clicked.)

> and I won't 
> want to see any mouse() method in my apps really.

If you write apps using the Lob system, you won't be writing mouse() 
methods, I believe. Each lob will have a mouse() method but you will 
never write them or use them directly.

> Hmm. I think that we should also pass trough all mouse events and not just 
> clicks, button down/released and drags. That would say in two seconds 
> whether the event handling is enough fast.

We can do that, the only problem is how the API should look. We will 
want to pass around a VobMouseEvent, I think, but then the question is 
how we will pass the coordinates of the event, because VobMouseEvent 
contains the coordinates relative to the vob scene, but we need to pass 
the coordinates relative to the called lob.

I see two relatively simple possibilities, either modify the values 
inside the VobMouseEvent (which isn't too neat), or pass around a 
VobMouseEvent *plus* an x/y coordinate, which is bad because the 
VobMouseEvent itself also contains x/y which is confusing.

Of course we could also change VobMouseEvent, removing the x/y, and pass 
it along with VobMouseEvent everywhere it is used.

> > > 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 
> actually the model should do it). Even if it still almoust fast enough 
> with bigger scene it definitely is not.

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.

With what we have now -- discrete changes when the user clicks on 
up/down -- actually you don't just want to change parameters because you 
want to have animated scrolling...

Cheers,
- Benja