[Top][All Lists]

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

Re: [Fenfire-dev] CLI

From: Benja Fallenstein
Subject: Re: [Fenfire-dev] CLI
Date: Thu, 22 Jul 2004 02:49:53 +0200
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040715)


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

- Benja

reply via email to

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