Re: [Fenfire-dev] CLI

[Benja Fallenstein]

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

    http://vintage.fresco.org/tutorial/
    http://www.fresco.org/reading.html

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

    http://vintage.fresco.org/tutorial/c147.html

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

    http://c2.com/cgi/wiki?ModelViewControllerHistory

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

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?

Cheers,
- Benja