To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=56304
------- Additional comments from [EMAIL PROTECTED] Fri Dec 2 03:51:18 -0800
2005 -------
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.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
