Migration to SWT Designer

[vroubine]

Dear SWT Designer Team,

we have a huge Migration project and we are planning to migrate our old Eclipse RCP Code to the SWT Designer. So, we have a big productive Eclipse RCP Client with a set of proprietary widgets (they encapsulate the SWT und Nebula widgets) and in the future we would like to use SWT Designer for better forms design and for better communication with the domain experts. We are actually in the evaluation phase right now and want to meet a decision whether to use or not to use the Designer. Technically, we have the following challenges:
1) Our widgets encapsulate SWT and Nebula widgets and do not inherit from Composite;
2) We use factories to create Widgets and our constructors do not have only two parameters (Composite parent, int style), but much more, e.g. whether widget is mandatory, expandable, read only and so on;
3) For creating some sub-widgets, we are not using constructors but FormToolkit
3) We can attach default Actions (our proprietary Actions) to widget
4) Unfortunately, when we started (several years ago), we did not use Eclipse Data Binding, but created our own framework, which is based on IDs of widgets, etc.

Could you help us and give hints how to refactor such kind of widgets in order to be compatible with the SWT Designer. Do you have already experience with such migration projects. Could you please provide us with a precise guide how to create a widget compatible with the SWT Designer. I suppose that similar requirements are coming from more and more customers, since plenty companies have proprietary widgets and/or frameworks...

Thank you.

Best Regards,
vroubine

[Eric Clayberg]

1) Our widgets encapsulate SWT and Nebula widgets and do not inherit from Composite

What do they inherit from? In order to use the widgets with SWT Designer, they should conform to SWT widget standards. See...

http://download.instantiations.com/D2WB ... tomWidgets

Also review the New Component Tutorial and Customization API docs.

2) We use factories to create Widgets and our constructors do not have only two parameters (Composite parent, int style), but much more, e.g. whether widget is mandatory, expandable, read only and so on

We do support creating and using widget factories...

http://download.instantiations.com/D2WB ... ories.html



Factories should be marked with a @wbp.factory Javadoc tag.

3) For creating some sub-widgets, we are not using constructors but FormToolkit

We currently support FormToolkit-based factories.

4) We can attach default Actions (our proprietary Actions) to widget

Custom properties may require a custom editor.

5) Unfortunately, when we started (several years ago), we did not use Eclipse Data Binding, but created our own framework, which is based on IDs of widgets, etc.

SWT Designer should not care about any custom code that you happen to add. You can intermix it with the generated code. Any properties that follow JavaBean conventions will show up in the properties pane.

Could you help us and give hints how to refactor such kind of widgets in order to be compatible with the SWT Designer.

I would suggest playing with the existing Factory support and generating a few examples. It should not be too hard to adapt your own factories to work in the same way. True custom widgets would need to inherit from org.eclipse.swt.widgets.Control.

I suppose that similar requirements are coming from more and more customers, since plenty companies have proprietary widgets and/or frameworks.

We have seen almost none like this. Most folks who make custom widgets tend to have them adhere to Swing or SWT standards as that makes them much easier to use and maintain.

[vroubine]

Dear Eric,

thank you so much for the detailed reply! We continue our experiments.

@: This is the main challenge for us now to come from proprietary widgets to Eclipse standard mechanisms with the support of SWT Designer. This is exactly the case where the common advice "encapsulate and not inherit" works against us...

Best Regards,
vroubine

[Eric Clayberg]

This is exactly the case where the common advice "encapsulate and not inherit" works against us.

Encapsulation works fine, and most folks create custom SWT widgets that way. The problem is that you appear to have used encapsulation incorrectly in this case. The proper encapsulation approach would have been to wrap your custom widgets within an SWT Composite (exposing only the properties you wanted to expose), so that they would have remained within the SWT framework and qualified as real SWT widgets. Encapsulating them in some other random framework just means that you have, in effect, created your own unique GUI API that is not SWT, RCP, Swing or anything else recognizable to the GUI builder. See the following Eclipse.org article for details...

http://www.eclipse.org/articles/Article ... Widget.htm

I would recommend re-parenting the framework under the SWT Composite class or using factories that return real SWT preconfigured widgets. >95% of the existing SWT custom widgets available on the Web are subclassed from Composite (or one of its children like Canvas) with the remainder subclassed directly from the parent widgets (not recommended unless you are doing something very simple that only involves public API).

[vroubine]

Yes, you are absolutely right, re-parenting the framework is exactly what we are planning to do. Another idea would be to reimplement the framework, but it is already style-guide conformed and also contains a set of important features (text autocompletion, context management, decorations, etc...).

As an example, I've created a small SWT-compliant class for the text input field (our simplest widget), see attachment. I have the following issues:
1) I can not use the SWT-Designer Design Mode for this class, probably since we are using FormToolkit;
2) When putting widget to the View, in the properties I see only "mandatory" field, "uiElementContext" is not seen.
3) When creating factory from the widget, in the "Creation Arguments" I see only "parent" and "style" attributes, the others are not available. For us, it is important that we have a possibility to pass multiple arguments, such as context, to the factory method.
(We are currently evaluating the 14-days trial version of 7.6.0 WindowsBuilderPro for Eclipse 3.5.2)

Unfortunately I have to bother you with this set of technical questions, cause we have to meet the decision about using SWT Designer rather soon. This decision is crucial for a huge project, thus we have to get a feeling about stability and scalability of your tool.

Thank you in advance.

Best Regards,
vroubine

[Eric Clayberg]

1) I can not use the SWT-Designer Design Mode for this class, probably since we are using FormToolkit;

No. FormTookit is not a problem. The problem is with the non-typical way you initialized it. Try this instead...

Code: Select all

private static FormToolkit formToolkit = new FormToolkit(Display.getDefault());

...or update to the latest v7.6 build where we added parsing support for static initializers like the one you are using.

2) When putting widget to the View, in the properties I see only "mandatory" field, "uiElementContext" is not seen.

I see all the properties...

properties.png (37.52 KiB) Viewed 465 times

3) When creating factory from the widget, in the "Creation Arguments" I see only "parent" and "style" attributes, the others are not available.

The only factory properties you will see are the ones you configured for the instance you are deriving the factory from.

factory.png (109.59 KiB) Viewed 465 times

For us, it is important that we have a possibility to pass multiple arguments, such as context, to the factory method.

Yes. That is exactly how it works now.

we have to get a feeling about stability and scalability of your tool.

The product is both very stable and very scalable and has won many industry awards.