Hallo!
Post by jmdrakeBluebottle still supports System 3, but it's kind of like running
System 3 under Windows or Unix X11. The XML user interface is more
<Panel title="Temporary Menu" width="250" height="380" color="C0C0C0FF">
[...]
Post by jmdrake</Panel>
This creates the "main menu" which is a series of 8 buttons and
a textbox. Unfortunately it's still in "flux" and needs a lot
of work, but I've seen some interesting stuff done with it.
OK, that is not as different as I thought but there are differences that
Post by jmdrake<Panel title="Temporary Menu" width="250" height="380" color="C0C0C0FF">
In VisualOberon you normally do not give objects fixed sizes. You can
give them fixed sizes but normally you use relative measurements (if you
use a measurement at all). For example you can tell an object that is
has the size of 50% of the desktop (of course it is a good idea to do
this only for top level objects else you might get dialogs that are
bigger than the screen).
In most cases is is however enough to tell an object that is can change
it horizontal or vertical size and leave the actual sizing to the
container that holds the objects or a collection of objects. You then
choose the container that fits you needs. VisualOberon will then
calculate the object and in the end the dialog size itself and
VisualOberon will handle resizing of dialogs in an intelligent way.
What happens in your XML code if you change the size of the font (since
the font is not part of the XMl code, it is not fixed)? Likely it would
not be usable anymore. In VisualOberon you just get a bigger dialog!
This may result in too big dialogs if you use strange fontsizes but the
dialog would still be useable.
An area I would like to put more investigation is to use objects that
change their layout if certain limits are meet (however there was no
need, since I currently do not run programs on desktop computer and for
exmaple PDA) or where their layout can be changed dramatically by
configuration (I call them abstract layouting objects). For example
there is an layouting object that tries to choose different
visualisations of labeled items (a list of items where every items
contains of a textual label and an structured object). Depending on the
total number of list entries it uses a tab object, a table, where a
selctions switches the view of the current object or a combobox instead
of a table.
Same procedure could be used e.g. for wizard dialogs. You could change
the look of the dialog compeltely and VisualOberon would calculate it to
fit.
VisualOberon XML normally does not contain colors since major point of
the usibility of a GUI is fullfilled expetations and standarized
behaviour. So a color sheme is defined at a central place and all
objects use this color sheme. This is even true for Windows ;-)
Post by jmdrake<Button title="Oberon" align="top" height="50" onClick="runner Execute">
VisualOberon does not know of commands.This is not a problem of VO
itself, it is just that the runtime system of the oo2c compiler does not
allow it. VO uses a more conventional model driven aproach together with
a message delegation system (messages can be delegated to any message
handling object and can even get convert to another message on its way).
The MVC concept separates viewing and (re)action, so embedding command
execution in display dexcription code could be discussed (however VO is
also more M-(VC) than M-V-C);-)
How do the "onClick" attribute and the SystemCommand tag interact. Looks
like a mixture of classic command driven Oberon System and some MFC or
QT stuff where you have defined actions?
You would also never tell an object that it should align something to
the left, the object class would allow differnet styles and you would
the configure the alignment handling for each style in a configuration file.
All these differences do have the aim the extract and abstract as much
of the object layouting and put as information into the layouting system
as possible. Instead of defining a flat dialog you defined hierachical
relations. This has advantages:
* Defining a GUI gets simpler, since much more is automatic.
* The GUI looks smart.
* The GUI is easily themable (and VO does proof this!).
* The GUI is drastically adpated to different display needs.
* GUI can to some degree be configured to like like the native GUI.
* GUIs are consistent.
* The GUI can be changed without changing the program
* The Look can be changed without changing ther program
* Good for rapit protoyping
* Good for automatic code generation
Post by jmdrake<Panel title="HelloWorld" width="100" height="100">
<Label caption="Hello world!" align = "top" height="50"/>
</Panel>
OK, obviously you left some tags ;-). If I strip down the example to the
Post by jmdrakePost by Tim Teulings<WindowGroup>
<Main>
<Text text="Hello world!"/>
</Main>
</WindowGroup>
You see: Positioning is gone and a layouting groupd has apeared
(WindowGroup has also slots for a menubar, a toolbar and a statusbar).
Post by jmdrakeGood. I'll take a look at it. Thanks for the info and keep up the good
work!
fine, seeing and using it might explain it better :-) I would suggest to
take a look at the current CVS version, since I smoothed the XML
handling a little bit since your last mail :-) There is now a tool that
spits out some documentation for each object. If you have any problems,
mail me /this is of course an offer for everybody else out there who
wants to test VisualOberon!).
While I used your mail to show the differences, I'm of course still
interested in some cooperation and knowledge transfer.
--
Gruß...
Tim.