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