Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||sample implementation of layout engine for dialogs (springlayout)|
|Status:||CLOSED NOT_AN_ISSUE||QA Contact:||issues <issues.openoffice.org>|
|Priority:||P3||CC:||davidf, issues, mmeeks, nesshof, oo|
|Target Milestone:||OOo 3.0|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
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 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 7 caolanm 2005-10-20 09:29:44 UTC
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 problem
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): http://go-oo.org/ooo-build/patches/test/layout-ids.diff http://go-oo.org/ooo-build/patches/test/layout-rsc.diff http://go-oo.org/ooo-build/patches/test/layout-test.diff http://go-oo.org/ooo-build/patches/test/layout-vcl-layout.diff http://go-oo.org/ooo-build/patches/test/layout-vcl-window.diff 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: Shared * both need a widget measurement API - 'give me your preferred size' Containment: * 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. Springs: * 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
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 dev@gsl. 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 http://wiki.services.openoffice.org/wiki/VCL_UI_Rework 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