Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 324082 - [Theming] ThemeAdapters return wrong values for subclassed widgets
Summary: [Theming] ThemeAdapters return wrong values for subclassed widgets
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.4   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 1.5 M3   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-31 08:55 EDT by Ralf Sternberg CLA
Modified: 2011-10-25 03:21 EDT (History)
2 users (show)

See Also:


Attachments
Test case (2.39 KB, patch)
2010-08-31 08:56 EDT, Ralf Sternberg CLA
no flags Details | Diff
Test case (3.89 KB, patch)
2011-10-24 07:05 EDT, Stephan Leicht Vogt CLA
rsternberg: iplog+
Details | Diff
Proposed solution (1.39 KB, patch)
2011-10-24 07:05 EDT, Stephan Leicht Vogt CLA
rsternberg: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Sternberg CLA 2010-08-31 08:55:06 EDT
See attached TestCase
Comment 1 Ralf Sternberg CLA 2010-08-31 08:56:12 EDT
Created attachment 177830 [details]
Test case
Comment 2 Ivan Motsch CLA 2011-05-26 10:08:40 EDT
As described in forum http://www.eclipse.org/forums/index.php/m/674212/#msg_674212
here a proposal for a solution to this ticket.
--

A ui to widget mapping - from an architectural point of view - should not just be measured on how strict or straight-forward (class names...) it is but how and where it is extendible, where it is not, and how flexible it is.
In short: Good design is simple, flexible and extensible in its main aspects BUT may be strict, closed and final in its side aspects.

May I point to a very similar area of architectural design pattern regarding ui mapping in swing.
Swing has as it's core concept the separation of widgets (JButton, JTextField) and their ui (ButtonUI, TextFieldUI). A look- and-feel (or theme) is created by creating a ui layer for example SynthButtonUI, SynthTextFieldUI etc.

The connecting glue between widget and ui is JComponent.getUIClassID();
public String getUIClassID() {
return uiClassID;
}
Every subclass of JComponent may overwrite the UIClassID property (for example ComponentUI, ButtonUI, TextFieldUI, etc.)

Also in swing it is not recommended to subclass swing widgets. However sometimes it is done and necessary to work around bugs and features coming too late to the project.
The way swing maps widgets to ui is simple, flexible and extensible.

As it is not realistic to extend SWT's Widget with a property "getUIClassID" we may use the SWT idea of extension. "Adapters".
RWT may add the IUIClassAdapter to their widget implementation.

public interface IUIClassAdapter{
String getUIClassID();
}

The rwt ui mapper may simply call String uiClass=((IUIClassAdapter)aWidget.getAdapter(IUIClassAdapter.class)).getUIClassID();
Whether or not a swt widget is a subclass does compromise ui mapping. There is no drawback to todays solution. That way is more flexible, backward compatible to JRE1.4 and eclipse 3.4 and reduces swt design impacts on rwt ui mapping.
From a design and architecture point of view a "better" solution.
Comment 3 Stephan Leicht Vogt CLA 2011-10-24 07:04:27 EDT
I have a easy solution for this problem. It would help us a lot, if this patch would be approved and committed.
Comment 4 Stephan Leicht Vogt CLA 2011-10-24 07:05:22 EDT
Created attachment 205799 [details]
Test case

Makes the Patch from Ralf obsolete.
Comment 5 Stephan Leicht Vogt CLA 2011-10-24 07:05:55 EDT
Created attachment 205800 [details]
Proposed solution
Comment 6 Ralf Sternberg CLA 2011-10-24 17:45:11 EDT
Thanks for the patches, Stephan. I applied them to CVS with some changes.
In particular, I removed the fallback to the simple class name, which I believe was obsolete.
Comment 7 Stephan Leicht Vogt CLA 2011-10-25 03:21:49 EDT
Thanks for the fix.