Home » Eclipse Projects » Remote Application Platform (RAP) » AbstractThemeAdapter#getPrimaryElement
| AbstractThemeAdapter#getPrimaryElement [message #672021] |
Thu, 19 May 2011 11:24  |
|
Hi
I overwrite a Widget (for example a Button) to be able to debug like this:
Button button = new Button(parent, style | SWT.FLAT | orientation) {
public void setForeground(Color color) {
if (color != null) {
System.out.println(color);
}
super.setForeground(color);
}
};
Now I continue with following setting:
CSS:
Button {
color: red;
}
Java:
button.setForeground(null);
Color buttonColor = button.getForeground();
The color buttonColor will not be red as mentioned in the css but
something different. Thats because
AbstractThemeAdapter.getPrimaryElement(final Widget widget) searches the
underlying css elment with widget.getClass(), which is in our example
FormToolkit$1.
My question is: Why getPrimaryElement has to search the css element by
the class of the widget? AbstractThemeAdapter is overwritten by the
ButtonThemeAdapter and imho should know that the css element is "Button".
Can someone enlighten me in this matter?
Thanks and greetings
Stephan
|
|
| |
| Re: AbstractThemeAdapter#getPrimaryElement [message #672229 is a reply to message #672039] |
Fri, 20 May 2011 07:44  |
|
Hi Ralf
You're right, the bug 324082 [1] describes my problem.
Unfortunately not sub-classing the button or other widgets is sometimes
not a option. And since the swt faq just states that sub-classing is not
recommended, I don't see a problem to use this mechanism in special cases.
About my example for the debugging: Sometimes I just want to step into a
method invocation of a certain instance of a class. So this is imho the
simplest way to do it. If there is a simpler way please tell me.
My last question is still unanswered. Why isn't the ButtonThemeAdapter
not aware that the css representation is "Button". Why does it have to
search the representation via the class of the widget?
Kind regards
Stephan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=324082
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #672861 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #672877 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #672884 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #672912 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #672947 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #672955 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #673052 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #673058 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #673072 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #673127 is a reply to message #672229] |
Sun, 22 May 2011 07:31 |
|
Hi Stephan,
> Unfortunately not sub-classing the button or other widgets is sometimes
> not a option. And since the swt faq just states that sub-classing is not
> recommended,
You're right, the SWT article does not exclude the option to subclass.
But only "in extreme circumstances" and when "all other avenues have been
explored and exhausted". From my experience with SWT I can say that I've
hardly ever come to this point and I always found better ways than
subclassing to resolve problems.
> I don't see a problem to use this mechanism in special
> cases.
The SWT article list a number of problems. Moreover, the fact that SWT
throws an exception if you subclass widgets, and the warning in the
widget's API doc
* IMPORTANT: This class is intended to be subclassed <em>only</em>
* within the SWT implementation.
makes it pretty clear that this is not officially supported API. If you
go this path, you are on your own.
> About my example for the debugging: Sometimes I just want to step into a
> method invocation of a certain instance of a class. So this is imho the
> simplest way to do it. If there is a simpler way please tell me.
You can simply open the class in the Eclipse editor, set a breakpoint at
the line that you want to step into (right click at the left editor
border or Ctrl+Shift+B). Then start the application in debug mode (Run >
Debug Configurations... ). It will stop there and let you inspect the
value of all variables.
> My last question is still unanswered. Why isn't the ButtonThemeAdapter
> not aware that the css representation is "Button". Why does it have to
> search the representation via the class of the widget?
There were some corner cases that lead to this implementation, but I
don't remember the details anymore. It might well be that the cause
doesn't even exist anymore do to the refactorings that we made in this
area meanwhile. The solution is clearly problematic for custom widgets
and will be revised with bug 324082. But believe it or not, there are a
number of non-trivial constellations in the theming and changing this
place requires careful testing. Unfortunately it's too late for 1.4.
However, I would rather help you to find a better solution for your
problem than to discuss an issue that you would not have otherwise.
Could you outline the problem that caused you to subclass Button? Which
behavior or appearance did you add?
Best regards, Ralf
--
Ralf Sternberg
Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/
Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
|
|
|
| Re: AbstractThemeAdapter#getPrimaryElement [message #673614 is a reply to message #672861] |
Tue, 24 May 2011 04:43 |
|
Hi Ralf
> Could you outline the problem that caused you to subclass Button? Which
> behavior or appearance did you add?
I just stepped over an quite simple example which I did not find another
easy solution rather then subclassing.
Composite container = new LayoutComposite(parent, SWT.NO_FOCUS);
CLabel label = new CLabel(container, SWT.NO_FOCUS);
Text text = new Text(container, SWT.SINGLE) {
@Override
public void setBackground(Color color) {
super.setBackground(color);
if (label != null) {
label.setBackground(color);
}
}
};
So I have a container with a label and a textfield in it. Now if from
somewhere the textfield gets a new background color the label should
also change its background color. I got this behavior by overwriting the
setBackground of the textfield. What would be the solution without
subclassing? I know I could write a Widget with the textfield as
property, but then I would have to expose every public method of Text in
this widget, right?
Thanks and greetings
Stephan
|
|
| |
| Re: AbstractThemeAdapter#getPrimaryElement [message #673684 is a reply to message #673634] |
Tue, 24 May 2011 09:19 |
 Ivan Motsch
Messages: 82
Registered: March 2010 |
Member |
|
|
It seems to me that the discussion is drifting away a little bit.
The concern is not swt's lack of subclassing concepts, the concern regards the
architectural design of rwt in which way it maps themes/ui to swt widgets.
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.
So why reinventing the weel, that kind of mapping is in place for almost 15 years now and did a good job for styleable and extendible look and feel concept.
I think that RWT does a brilliant job. It sits between SWT and Web2.0. The above discussion is - for my flavor - too swt centric. Please also address enough Web2.0 apsects since
RAP will in future more and more be compared to ZK, Vaadin and Google WTK.
Looking foreward to more fantastic RWT development, thanks guys.
[Updated on: Tue, 24 May 2011 09:36] Report message to a moderator |
|
| | |
| Re: AbstractThemeAdapter#getPrimaryElement [message #674665 is a reply to message #673684] |
Fri, 27 May 2011 15:21 |
|
Hi Ivan,
I'm sorry for the delay, I've not been able to follow up during the last days.
If I understand your proposal correctly, you suggest to introduce a mechanism that would allow to specify a certain type of styling for a widget.
Such a mechanism is already in place in RWT, it's called "Custom Variants". Those variants are comparable to classes in CSS. They are strings that can be attached to a widget using SWT's setData() method:
Text text = new Text( parent, SWT.SINGLE );
text.setData( WidgetUtil.CUSTOM_VARIANT, "mySearchField" );
In the theming, you can specify customized CSS parameters for those text fields, that have this custom variant:
Text.mySearchField {
padding: 5px 10px;
background-color: yellow;
...
}
Is this an acceptable replacement for the mapping you described?
Best regards,
Ralf
|
|
| | | |
Goto Forum:
Current Time: Mon May 20 13:11:28 EDT 2013
Powered by FUDForum. Page generated in 0.02463 seconds
|
] 
Search
Help
Register
Login
Home
