Constructed style names make it difficult to subclass
I'm not that familiar with the stylesheets, but the code in this method creates a rather painful-to-find display bug when subclassing adapters. It would be better, in my opinion, to explicitly return the style name string. If you try to subclass an adapter without knowing to override styleName will create display problems.
SpAbstractMorphicAdapter>>#styleName
"i.e. SpButtonAdapter = button"
^ ((self className withoutPrefix: 'SpMorphic') allButLast: 7) uncapitalized
Example:
I subclassed SpMorphicTextInputFieldAdapter and didn't add any methods. The resulting display was bizarre. Finding the problem was time-consuming.
| SpMorphicTextInputFieldAdapter | custom adapter subclass with no behavior |
|---|---|
This happened because the styleName method returned the wrong style name based on my subclass's name rather than using the superclass styleName as I expected would have happened.
Version:
Pharo 12.0.0
Build information: Pharo-12.0.0+SNAPSHOT.build.1571.sha.cf5fcd22e66957962c97dffc58b0393b7f368147 (64 Bit)
Also, it would be nice if the buildWidget methods didn't hard code the widget's class name. This would make the widget easier to subclass, too.
Example: SpMorphicTextInputFieldAdapter>>#buildWidget
buildWidget
| newWidget |
newWidget := (SpRubTextFieldMorph on: self)
getTextSelector: #getText;
setTextSelector: #accept:notifying:;
getSelectionSelector: #readSelection;
menuProvider: self selector: #codePaneMenu:shifted:;
...
A method: defaultWidgetName returning SpRubTextFieldMorph in this example could make the code more easily extended.
Tx Eric. Styleshhets in Morphic are really a hack compared to the ones of Toplo and GTK. We will have a look. Could you tell us if this is also happening in Pharo13?
Hi Stephane,
I haven't tried to get my code running in Pharo 13 yet, but I see the method SpAbstractMorphicAdapter>>#styleName has not been changed from Pharo 12. That gives me a hint that there's still a problem.