For the next release of Metawidget (v0.95), I'm going to have a go at some (long overdue) SWT support.
SWT is notorious for being difficult to work with for dynamic UIs. This largely seems to stem from the fact a Control cannot be created independent of a Composite (container): you have to specify a Control's Composite at construction time, so you can't easily remove it from a Composite temporarily, or move it from one Composite to another (eg. from outside to inside a TabFolder).
I got a huge leg up from Stefan Ackermann, who implemented a partial port of Metawidget to SWT for me, so things aren't going too bad so far. An alpha build is in SVN.
But it's early days yet. Any SWT experts who would like to lend a hand (coding or testing) are very welcome!
Wednesday, January 27, 2010
Monday, January 11, 2010
GUI Generator: Metawidget Video Overview
Had fun this weekend putting together a little 'video overview' of Metawidget. Music by Kevin MacLeod:
Tuesday, January 5, 2010
Automatic Interface: Metawidget v0.9
Version 0.9 of Metawidget, the automatic interface tool, is now available. Existing users should see the Migration Guide. This release includes the following enhancements:
http://metawidget.org/doc/reference/en/pdf/metawidget.pdf
Your continued feedback is invaluable to us. Please download it and let us know what you think.
- Nestable sections and pluggable LayoutDecorators
- Pluggable mechanisms for widget overriding (OverriddenWidgetBuilder) and read-only widgets (ReadOnlyWidgetBuilder)
- Pluggable InspectionResultProcessors
- Upgraded Android support (now includes 2.0, i18n, TabHosts)
- <enum> and <constant> support in metawidget.xml
- More bug fixes, unit tests and documentation
Your continued feedback is invaluable to us. Please download it and let us know what you think.
Metawidget 0.85 to 0.9 Migration Guide
The next release of Metawidget (v0.9) continues the refactoring work of v0.85. As such, there will be some breaking changes. We apologise for this disruption and provide this Migration Guide to help in moving from v0.85 to v0.9. All of the existing documentation and examples have already been migrated, as a reference point.
LayoutDecorators
The layout interface has been changed slightly to introduce the concept of LayoutDecorators. This allows inner layouts to be 'decorated' with outer layouts.
For example, you can decorate a GridBagLayout with a TabbedPaneLayoutDecorator to add tabs around sections. Previously this functionality was 'baked in' to GridBagLayout itself, and duplicated in other places such as MigLayout. Breaking it out allows easier maintenance, plus we can beef up the decorators themselves. For example, TabbedPaneLayoutDecorator now supports configuring tab alignment.
You can also nest LayoutDecorators in interesting ways. For example...
...gives (ie. nested tabs)...
...whereas...
...gives (ie. tabs inside a separator)...
...and finally...
...gives (ie. separators inside a tab)...
Another advantage of this approach is you can decorate widgets from one widget library with widgets from another: LayoutDecorators allows mixing layouts in the same way CompositeWidgetBuilder allows mixing widgets. For example, you can use JSF's SimpleLayout but decorate it with tabs using RichFaces' TabPanelLayoutDecorator:
InspectionResultProcessors
There is now a new stage in the pipeline for processing the inspection result after the Inspectors but prior to the WidgetBuilders. Existing functionality (such as sorting by comes-after) has been moved into here, but it also opens the door for custom implementations.
In particular, it allows sorting and/or including/excluding names based on a UI parameter. For example:
We don't necessarily recommend this approach (it requires hard-coding field names so won't refactor well) but it has been a common request.
OverridenWidgetBuilder
Previously widgets were overridden by adding child widgets (with appropriate names) inside the Metawidget. This mechanism has now been factored out into an OverridenWidgetBuilder so that custom implementations can be plugged in instead if desired. Alternatively, you can remove the overridden mechanism entirely.
ReadOnlyWidgetBuilder
Previously all WidgetBuilders had two code paths: one for read-only widgets and one for non-read-only (or 'active') widgets. This has been factored out into a separate ReadOnlyWidgetBuilder so that custom implementations can be plugged in instead if desired. Alternatively, you can remove the read-only mechanism entirely.
LayoutDecorators
The layout interface has been changed slightly to introduce the concept of LayoutDecorators. This allows inner layouts to be 'decorated' with outer layouts.
For example, you can decorate a GridBagLayout with a TabbedPaneLayoutDecorator to add tabs around sections. Previously this functionality was 'baked in' to GridBagLayout itself, and duplicated in other places such as MigLayout. Breaking it out allows easier maintenance, plus we can beef up the decorators themselves. For example, TabbedPaneLayoutDecorator now supports configuring tab alignment.
You can also nest LayoutDecorators in interesting ways. For example...
<tabbedPaneLayoutDecorator xmlns="java:org.metawidget.swing.layout"
config="TabbedPaneLayoutDecoratorConfig">
<layout>
<tabbedPaneLayoutDecorator config="TabbedPaneLayoutDecoratorConfig">
<layout>
<gridBagLayout />
</layout>
</tabbedPaneLayoutDecorator>
</layout>
</tabbedPaneLayoutDecorator>
config="TabbedPaneLayoutDecoratorConfig">
<layout>
<tabbedPaneLayoutDecorator config="TabbedPaneLayoutDecoratorConfig">
<layout>
<gridBagLayout />
</layout>
</tabbedPaneLayoutDecorator>
</layout>
</tabbedPaneLayoutDecorator>
...gives (ie. nested tabs)...
...whereas...
<separatorLayoutDecorator xmlns="java:org.metawidget.swing.layout"
config="SeparatorLayoutDecoratorConfig">
<layout>
<tabbedPaneLayoutDecorator config="TabbedPaneLayoutDecoratorConfig">
<layout>
<gridBagLayout />
</layout>
</tabbedPaneLayoutDecorator>
</layout>
</separatorLayoutDecorator>
config="SeparatorLayoutDecoratorConfig">
<layout>
<tabbedPaneLayoutDecorator config="TabbedPaneLayoutDecoratorConfig">
<layout>
<gridBagLayout />
</layout>
</tabbedPaneLayoutDecorator>
</layout>
</separatorLayoutDecorator>
...gives (ie. tabs inside a separator)...
...and finally...
<tabbedPaneLayoutDecorator xmlns="java:org.metawidget.swing.layout"
config="TabbedPaneLayoutDecoratorConfig">
<layout>
<separatorLayoutDecorator config="SeparatorLayoutDecoratorConfig">
<layout>
<gridBagLayout />
</layout>
</separatorLayoutDecorator>
</layout>
/tabbedPaneLayoutDecorator>
config="TabbedPaneLayoutDecoratorConfig">
<layout>
<separatorLayoutDecorator config="SeparatorLayoutDecoratorConfig">
<layout>
<gridBagLayout />
</layout>
</separatorLayoutDecorator>
</layout>
/tabbedPaneLayoutDecorator>
...gives (ie. separators inside a tab)...
Another advantage of this approach is you can decorate widgets from one widget library with widgets from another: LayoutDecorators allows mixing layouts in the same way CompositeWidgetBuilder allows mixing widgets. For example, you can use JSF's SimpleLayout but decorate it with tabs using RichFaces' TabPanelLayoutDecorator:
InspectionResultProcessors
There is now a new stage in the pipeline for processing the inspection result after the Inspectors but prior to the WidgetBuilders. Existing functionality (such as sorting by comes-after) has been moved into here, but it also opens the door for custom implementations.
In particular, it allows sorting and/or including/excluding names based on a UI parameter. For example:
<m:metawidget value="#{foo}" fields="name,age,retired"/>
We don't necessarily recommend this approach (it requires hard-coding field names so won't refactor well) but it has been a common request.
OverridenWidgetBuilder
Previously widgets were overridden by adding child widgets (with appropriate names) inside the Metawidget. This mechanism has now been factored out into an OverridenWidgetBuilder so that custom implementations can be plugged in instead if desired. Alternatively, you can remove the overridden mechanism entirely.
ReadOnlyWidgetBuilder
Previously all WidgetBuilders had two code paths: one for read-only widgets and one for non-read-only (or 'active') widgets. This has been factored out into a separate ReadOnlyWidgetBuilder so that custom implementations can be plugged in instead if desired. Alternatively, you can remove the read-only mechanism entirely.
Subscribe to:
Posts (Atom)