Issue 56304

Summary: sample implementation of layout engine for dialogs (springlayout)
Product: gsl Reporter: caolanm
Component: codeAssignee: caolanm
Status: CLOSED NOT_AN_OOO_ISSUE QA Contact: issues <>
Severity: Trivial    
Priority: P3 CC: davidf, issues, mmeeks, nesshof, oo
Version: OOo 2.0   
Target Milestone: OOo 3.0   
Hardware: All   
OS: Linux, all   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
patch5, sample usage for zoom dialog
starting size
successful layout on user expansion of dialog none

Description caolanm 2005-10-20 09:13:28 UTC
Attached is a sample implementation of a simple springlayout layout system for
controls in a dialog, and a sample example of the infamous zoom dialog with
added springs to use the layout engine. I suggest it as a simple easy to
implement and available as a short term solution to dialog layout.
Comment 1 caolanm 2005-10-20 09:13:56 UTC
Created attachment 30652 [details]
Comment 2 caolanm 2005-10-20 09:14:19 UTC
Created attachment 30653 [details]
Comment 3 caolanm 2005-10-20 09:15:16 UTC
Created attachment 30654 [details]
Comment 4 caolanm 2005-10-20 09:16:04 UTC
Created attachment 30655 [details]
Comment 5 caolanm 2005-10-20 09:17:14 UTC
Created attachment 30656 [details]
patch5, sample usage for zoom dialog
Comment 6 caolanm 2005-10-20 09:19:55 UTC
By additionally adding a "GetPreferredSize" to Window and subclassing for
widgets to figure out their optimum size, i.e. min size required to show text in
button, and inputting that into the layout engine at "nPrefMin/Max = X" then the
extra space inside windows can be done away with as well.
Comment 8 caolanm 2005-10-20 09:33:14 UTC
Created attachment 30657 [details]
starting size
Comment 9 caolanm 2005-10-20 09:34:25 UTC
Created attachment 30658 [details]
successful layout on user expansion of dialog
Comment 10 caolanm 2005-10-20 09:36:23 UTC
cmc->ssa: For your consideration as a plausible solution for the dialog layout
Comment 11 mmeeks 2005-10-21 09:41:24 UTC
Of course the 'containment' layout prototype patch from those years ago is here
(for comparison):

Of course - the common element here is the need to determine the preferred
Window (widget) size. Indeed I assume that the:

+    virtual void        VtkAllocateSize( const Size &aSize );
+    virtual void        VtkRequestSize( Size &rSize );

methods in Window are really the basis for any proposed sol'n here.

Of course - all things considered, IMHO the XUL approach is preferable ridding
us of the evil that is RSC, providing rapid GUI development / prototyping,
removing the compile phase etc. etc. :-)

Either way - looks like an interesting prototype Caolan.
Comment 12 philipp.lohmann 2005-10-21 10:18:06 UTC
I for one welcome our new Layout overlords :-) Seriously, i like the idea very
much (as by the way i did the first time around with michael's work). And even
if we finally switched to XUL we could use this as an interim solution to get
rid of these "in italian button X is not large enought to hold its text" issues.
Comment 13 stephan_schaefer 2005-12-02 09:14:32 UTC
ssa->pl: please take over. I fully agree that we should try to find a short-term
solution for the layout problem in the OOo 3.0 time frame. We currently do not
have the resources for the XUL approach so we should do our own layout engine.
Would be great to see a sample dialog, may be one from the Writer's Format menu,
with tab pages etc.
Comment 14 mmeeks 2005-12-02 11:51:18 UTC
So - here is my spiel - as delivered to caolan as to why IMHO a containment
based scheme is better in the long run than a springs approach:

   * both need a widget measurement API - 'give me your preferred size'

   * use the existing hierarchical structure in .rc files to good effect
   * should thus allow the removal of explicit code to construct & initialize
incidental widgets: containers, labels etc.
      * hence saves code-size & also saves a load of numeric identifiers &
        hence lookups
   * consistent with modern UI layout - XUL (html+) of course is containment
based, gtk+ & Java are containment based etc. etc. Any future migration path
would most likely be to a containment system, which could easily be automated
from .?RC -> whatever but not (easily) with a spring approach.

   * easier to generate the UI designer changes
   * requires more explicit code to add springs
   * an evolutionary dead-end, containment is the future :-)

As it happens - the dialog implementations are quite heavy & chunky code-wise
already, and shrinking that is IMHO a good idea [removing loads of explicit
chained constructor function calls for widget setup] - also, having a migration
path to a future containment based (XUL?) layout engine is wise IMHO.

ie. springs looks to me like the quick-hack solution to retrofit a dying
toolkit, adding containment gives a cleaner, more sustainable direction, allows
some nice code size shrinkage & eases future migration :-)

Either way - no doubt I missed a few pros of the springs sol'n - no doubt Caolan
will oblige with his view.
Comment 15 philipp.lohmann 2005-12-05 11:14:27 UTC
Set target
Comment 16 caolanm 2005-12-05 14:42:04 UTC
I've no argument against as a container based approach, and both need a give me
your desired size alright. But I reckon that...

springs pros:
    + very easy to implement and retrofit incrementally, lines of code involved
quite small
    + simple enough that adding a uno api to the awt api to add springs to
dialogs for external scripting should be trivial enough as well
    + should lend itself to making writing a dialog editor easier
Comment 17 philipp.lohmann 2006-04-04 12:34:43 UTC
I think we should discuss on a way to proceed; either the spring approach or
michael's containment should be used in future. Please let us discuss this on

However until we decide on an approach i cannot commit this patch.
Comment 18 caolanm 2006-04-04 12:38:37 UTC
Don't commit that patch anyway, it's a demo and only a partial impl. If we want
to go down the springlayout route I can fix the implementation. 

Perhaps unset the "patch" field if you are getting hassle about patch statistics :-)
Comment 19 philipp.lohmann 2006-04-04 15:51:32 UTC
got me :-)
Comment 20 caolanm 2007-07-31 16:26:23 UTC
dead: See Not a total
loss though, I got SpringLayout implemented in gnu classpath out it it.
Comment 21 caolanm 2007-07-31 16:27:24 UTC