[Libreoffice-commits] .: Branch 'feature/layout' - README.layout

[Michael Meeks]

 README.layout |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

New commits:
commit c8815277b8067de30c3b02616698b9b0692b476f
Author: Ricardo Cruz <rpmcruz at alunos.dcc.fc.up.pt>
Date:   Fri Nov 26 15:24:01 2010 +0000

    add readme, previous commit was Ricardo's code too

diff --git a/README.layout b/README.layout
new file mode 100644
index 0000000..b346e41
--- /dev/null
+++ b/README.layout
@@ -0,0 +1,46 @@
+
+> 1) that's still rather primitive and broken stuff. It needs
+> quite a few hours of productive time. I probably should
+> have just ported the toolkit; I have been pretty much
+> working on it from scratch.
+> 
+> 2) I initially went with Window::SetParent() calling a virtual
+> Window::ChildAdded() handler (and a ChildRemoved()) for
+> the containers benefit.
+> 
+>   But now, you're supposed to call e.g. Box::PackChild(), and
+> that method is then responsible for calling Window::SetParent().
+> You must specify some dummy parent Window to your widget at
+> construction, which is wasteful, but there was a big problem with
+> the previous approach:
+>   internal widgets: when you extend a widget, you probably
+> don't want to deal with those. For instance, TabControl does
+> a SetParent() every time the tab is changed, which creates
+> all kinds of havoc.
+>   Also, you may not want a container to be associated with
+> a Window necessarily. But I am not sure how important that
+> is.
+> 
+> 3) I was now playing with the QueueResize() method and
+> LDialog (an extension of Dialog). I think we probably want
+> to have a couple of flags: needRecal and needAlloc, as
+> well as a cached requisition of type Size.
+>   When you call QueueResize(), needRecalc is set to true.
+> LDialog, on timeout, does a breadth-first iteration through its
+> children to find which widgets/containers need their size to be
+> recalculated. Once it hits a needRecalc node, it checks the new
+> size against the cached valued: if they differ needAlloc is set to
+> true, and it now calculates the size of the parent recursively until
+> the extent of the damage is fully identified. All nodes that are
+> children of that top node must then be removed from the
+> iteration...
+> 
+>   SizeRequest() (or GetPosSizePixel()) should return the previous
+> calculation if needRecalc is false...
+> 
+>   The toolkit code also worked I guess: though it seems to be
+> pretty flickering ATM. But it does unnecessary size calculations,
+> and probably size allocations too (otherwise, it wouldn't flicker).
+> 
+>   I will try to pin-down the algorithm later today, so that we have
+> finally a solid foundation for this thing.