why do we need a special class for that?
Why not just a StringMorph with correct background?

On 17/4/14 16:20, Ben Coman wrote:

Build 30507 integrated slice 11492 "Kill UpdatingStringMorph, UpdatingMenu, and NameInHaloMorph"
that removed class UpdatingStringMorph its subclass NameInHaloMorph. As a consequence the halo "morph label"
became hard to read. Compare the red circled areas in the snapshots from build.

Technically its pretty easy fix. Restoring just the #drawOn: part of NameStringInHalo (now subclassed from StringMorph) solves the problem as follows...
Adding...
    StringMorph subclass: #NameStringInHalo
        instanceVariableNames: ''
        classVariableNames: ''
        category: 'Morphic-Base-Widgets'

    NameStringInHalo>>drawOn: aCanvas
        aCanvas fillRectangle: self bounds color: Color white.
        super drawOn: aCanvas.

and modify the following line in HaloMorph>>addNameBeneath:string: ...
    nameMorph := StringMorph contents: aString font: StandardFonts haloFont.
to..
    nameMorph := NameStringInHalo contents: aString font: StandardFonts haloFont.

However I'm seeking a broader picture to understand if that is the right way to proceed...
1. Was NameStringInHalo particularly undesired or was it more a consequence of UpdatingStringMorph being removed ?

2. Should the same class name "NameStringInHalo" be used having a different superclass than before. Actually as I write that I am thinking this creates an unnecessary clash with Squeak and derivatives that still have NameStringInHalo, and so...

3. Any suggestions for another more generic class name? SolidStringMorph, OpaqueStringMorph, etc

4. Any suggestions for another way for a StringMorph to have a solid background?

cheers -ben