Hi again,
i have been thinking and trying to order the ideas in my mind to share
them with you in an ordered manner.
From your message, i guess you implicitly has objectives in mind. I will
comment some ideas i had and perhaps they are out of reach by now, but i'm
trying to grasp the main picture behind osgWidget (past, present and
future).
As far as i understand, osgWidget is a windowing toolkit, mainly 2D, to
overlay on top of a scene (ortho camera), i.e. it works around the common
abstraction of windows (main containers) and widgets (aka controls). These
are uptodate 2D in nature and one can't do much to control its aspect other
than styling, texturing and compose them hierarchically. Also, there are 3
specific Widgets' "aspects" or uses (Browser, PdfReader and VncClient) that
osgWidget give you. osgWidget give event handling, focus management, sizing
and z order (in the sense of a 2d windowing toolkit). Also, to build a
window it uses a ScriptEngine that use either Python or Lua to externalize
the window "template". Until here, I'm right?
Thats all what I have grasp from the code. Now my ideas:
There are many, many "evils" that osgWidget (or windowing toolkit in
general) has to face: Separation of concerns, input handling, easy of use
(from toolkit), abstractions difficulty, extensibility (endless windows
contents and aspects), ...
1) Windowing toolkits (X11, Qt, Windows Forms and lately Flex components
and WPF) , there seems to be a tendency forward a declarative programming
model vs an imperative one (Oh dear, i come from the windows world :) ).
Flex (flash components) and WPF has many common concepts in this line: They
both use XML for the "presentation" and combined with code behind "logic". I
suppose this came from the web world (HTML + javascript or server side code,
PHP, JSP, ASP, ...). This has some good pros: Separation of logic and
visuals, extensibility, easy of making forms (windows). So, the recent
discussion about the use of C++ or Lua for osgWidget, i add another one: The
possibility to have declarative programming model with the use of some
hierarchical domain specific language. Using a Scene graph for this (.osg or
.ive) can be a good starting point. It's mature, it's here to stay and it's
very extensible, hierarchical and perhaps in the near future it will have an
XML export file format to friendly editing offline. With a new
ScriptEngine as an adaptor this objective is not as far as it seems. Of
course, due to C++ being an imperative language, there is a need for an
adaptor or an intepreter for parsing and format a "declarative approach".
2) A declarative model tends to have a logic tree (example: a window
composed of a tabular set of buttons) and a visual tree (how is a button
represented or rendered, its border, its content, its color, ...). This
separation helps to design an UI in that you can face first what you need
and then how you will render it.
3) Container vs Window: The window is no more than a "widget" that is a
"widget container" with an specific aspect. Needed by the windowing
platform, it is necessary, but its logic can be more abstract: Being it a
specialization of a container. So, the concept of "Container" and "Content"
is really useful here. It is the composite pattern in the GoF world. Also,
as far as i know, osgWidget lacks of the concept of "listbox" (a container
of an indeterminate numbers of items).
4) Layout: Ouch, the damocles' sword of UI. All of us want the Windowing
toolkit to lay out the content automatically into a resizable container with
many options for alignment and ordering and tabbing and sizing and anchoring
and scrollbars, but also it must be easy to use and near transparent. So,
having this aspect extensible is good (unless you want to be many years
programming layouts). osgWidget already has it with Table, Frame, Box and
Canvas. I have notice in other toolkits (Flex, WPF) that layout is
implemented as a two passes process (traverse). One for measure and one for
positioning. Mainly, a parent has a definible area to position its resizable
children and also an intend about how to position them relatively to each
other. I think this generalization of layout is what has allow them to have
a very well designed extensible model regarding layout.
5) Why not a window could be positioned absolutely in 3d space (for
example following a node or moving in sync with an scene)? There is a good
base for starting out.
6) What about data binding?
So far, i'm being very ambitious with all these aspects. But this is not
an objectives list. They are just ideas. As you said, a full-blown UI
nodekit is unreachable uptodate. But i think, as a minimum, there can be a
solid base for, step by step, growing in this line. You have laid the first
stone (not a bad one). For sure, now, after you have coded osgWidget, your
expertise and your knowledge about what is achievable and not is very
precise.
Think over what I have
