Derrell Lipman schrieb:
> Sebastian, Fabian et al, I've seen quite a number of checkins recently
> with comments regarding new children handling. Is this in regards to
> the x/y/width/height layout vs widget discussions of a couple weeks
> ago? If you get a chance, I expect I'm not the only one who'd be
> interested in an explanation of what the current plans are.
Hi Derrell,
indeed this is the result of the discussion we had a while ago. The guys
from the RAP (Rüdiger, Frank, ...) team expressed the concern that they
had no generic way to build up the widget hierarchy without knowing the
layouts in advance. Christian with qxTransformer and Leander with his
GUI designer expressed similar concerns. Another request was that purely
manual positioning without using any layout managers should be possible.
I will explain in short how we initially implemented the children
handling and wow we have changed it:
Our initial approach:
- Each widget, which has children needs a layout manager
- The layout keeps a list of all child widgets
- Children are added to the layout and not to the parent widget
- This made it possible to implement custom tailored "add" methods.
e.g. for the grid: grid.add(child, row, column)
- Layout hints/properties can only be set through the layout -> only
valid layout properties can be set.
- No "add" method in the generic widget class. -> it is possible for
special widgets like the tree or combobox to implement a custom "add"
methods with their own semantics, which don't have to represent the
actual widget hierarchy. The combobox.add() method could e.g. add a
listitem to the combobox list, which is not part of the combobox widget
hierarchy.
Our new approach:
- Children handling has been moved back to the widget, but all
children handling methods are protected
- Special widgets, which need to implement their own "add" semantics
are still free to do so.
- There is a "Composite" class, which exposes all the children
handling methods a public methods. The "Composite" is similar to the old
"Parent" class with the exception that it is not abstract.
- We have added "getBounds()" and setBounds(top, left, width, height)"
methods, which can be used to set and query the widget position without
any layout manager.
- If the parent already has a layout manager and "setBounds()" is
called on the child, the layout manager will ignore this child. This way
it is possible to layout most children using a layout manager but
positioning others manually.
Our initial approach is perfect for manually building up the GUI and I
still think that it is a good solution - Qt uses this approach with
great success. On the other hand does it make life harder for some
existing qooxdoo users to make the transition to 0.8.
The almost all changes are related to children handling. None of the
layout algorithms changed and all of the other new layout features still
work the same as before.
I hope this helps,
Best Fabian
--
Fabian Jakobs
JavaScript Framework Developer
1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
