[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: Sun, 18 Jul 2004 15:27:02 +0200
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040715)

Hi Matti!

Matti Katila wrote:
Benja could you express some words of the lob architechture?

Sure! :-) I'm not going to completely document it before it has stabilized, because a complete documentation for a feature would be wasted if I then go on to refactor how that feature works and need to write all the documentation again, but I'm very willing to discuss (and, of course, document anything that's necessary now).

Fundamentals: A lob is on the level of a Java Component or an InterViews Glyph. However, instead of drawing directly to the screen, it creates vobs in a VobScene. Lobs can be more fine-grained than Java components, too; for example, every character or word in a text can be a different lob (used in linebreaking). Well, you probably knew that much already.

Oh BTW, if anyone's reading this who doesn't know about Fresco/InterViews, you may want to have a look at


The Lob system is built on Fresco/InterViews ideas.

I'm building lobs because after looking at Haystack in spring, I came up with some scenarios of how I might like Fenfire to work which require a bit more PUI-like stuff, like a Haystack-like sidebar with menus and "UI continuations," i.e. dialog box-like things that are in the sidebar so that you can move through the structure and pick nodes as parameters to the action represented by the dialog box. (For example, "send by e-mail" or so.)

The two fundamental ideas about the lob system are, I guess,

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

- Allow complex *types* of lobs -- for example, 'scrollbar' -- to be built as a structure of simpler lobs. Basically, you can create a template for a scrollbar, and declare some parts of it to be 'parameters.' This is specific to the lob system, as far as I know.

Of course, without the second feature, you could still write

    Lob scrollbar(... parameters ...) {
        ... construct the scrollbar ...
        return scrollbar;

which would get called every time you create a new scrollbar, and which would create a structure of simpler lobs as the scrollbar. So as long as we're only discussing Java code there's not so much advantage from that. The interesting part is that we can define an RDF structure or other declarative language for lobs, and then we can create complex types of lobs in the structure.

This also means that we could write a 'lob editor' application/applitude that would allow you to compose lobs through a visual interface, so that new components can be created without programming.

I want the lob system to include a set of components, i.e. buttons, scrollbars, text fields etc., which are themeable. The component objects, i.e. Scrollbar and so on, will only provide the interface for the programmer; the actual functionality (drawing and event processing) will be delegated to a lob that the component requests from a Theme object. The themes, of course, are supposed to also be definable in structure.

I intend for the Loom VanishingWheelView to also become a lob, although not one built up from others, but a complex primitive lob. This will allow it to be part of a bigger layout of lobs, so that I can create a loom view with a sidebar, for example. Also the individual nodes placed by the view should be lobs, too, so that the full power of the Lob framework is available for them. (For example you could have a node that is a button, if you like.)

The lob system uses an MVC (model/view/controller) architecture with "value models," i.e., models containing only a single value, like a boolean that specifies whether a particular button is currently active or not. To learn more about this, see


which uses the word "subject" instead of "model," though. For a bit of history on MVC, see


-- according to that page, value models were introduced in the VisualWorks dialect of Smalltalk around 1991. This is also where I got the term "value model" from.

The interesting thing about the value model pattern is that you can create a model that is just a filter over a different model. So for example you can have three scrollbars, each with their own "current value" model, and create a "color model" which uses the three "current value" models for its R, G, and B values, and then have a filled rectangle on the screen that uses that color model, and then you have created a simple color picker. The fresco example referenced above is something like this.

Now this all is very useful for Libvob and Fenfire, because it can be used entirely independently of Fenfire and RDF, as it is used in Fresco/InterViews, but you can also create models that are filters over an RDF graph. So you can be independent of an RDF graph and store all status information in memory, or you can use a graph to store all the information in your application -- and you can switch between the two with changes only in one small part of your application.

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.


Images are similar, but a bit harder because there is no nice ImageVob that shows an image loaded from an arbitrary InputStream and that works in both AWT and GL...

If we had that, images would be straight-forward ;)

I'm not very familiar with the code but it seemed not to be "zoomable"

In theory it's zoomable, you'd just need to add a ZoomLob that creates a zoomed coordinate system and passes that to its child's render() method.

However, in practice, because of non-linear text scaling (at least in AWT), this will probably be a bit more tricky.

nor use libvob as fast as it could use it?

How so?

- Benja

reply via email to

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