[Cuis-dev] BoxedMorph padding

[Juan Vuletich]

Hi Bernhard,

(below)

On 9/8/2024 2:32 PM, Bernhard Pieber via Cuis-dev wrote:
> Hi Juan,
>
> Hmm, as padding is defined as the inner distance between the border and the content shown inside that border I don't understand why padding should not make sense if a border makes sense? Why should AutoCompleterMorph, ProgressBarMorph, and PasteUpMorph for example not have a padding? AutoCompleterMorph and ProgressBarMorph might even look better with a bit of it.
>
> I agree for DraggingGuideMorph, LayoutAdjustingMorph, HandMorph and HaloMorph, but then that's because a border does not make much sense. Hmm, why do they subclass BoxedMorph in the first place? I tried setting borders to LayoutAdjustingMorph, HandMorph and HaloMorph but none were shown. Is it because they need the extent ivar? If yes, how about the following hierarchy?
>
> PlacedMorph: location, layoutSpec
>      MorphWithExtent: extent
>          BorderedMorph: color, borderWith, borderColor, padding
>
> Cheers,
> Bernhard

This is a very good proposal. I'd just rename MorphWithExtent -> 
BoxMorph. So, we could have:

PlacedMorph: location, layoutSpec
     BoxMorph: extent
         BorderedBoxMorph: color, borderWith, borderColor, padding

And the hierarchy would be:

BoxMorph subclasses (besides BorderedMorph):
#(#DraggingGuideMorph #HaloHandleMorph #HaloMorph #HandMorph 
#InnerPluggableMorph #LayoutAdjustingMorph #MenuLineMorph #PasteUpMorph 
#ResizeMorph) .

BorderedBoxMorph subclasses:
  #(#AutoCompleterMorph #ImageMorph #LabelMorph #PluggableMorph 
#ProgressBarMorph #TextParagraphMorph #TileResizeMorph #TranscriptMorph) .

Additional BorderedBoxMorph subclasses, with borderWidth typically zero, 
but possibly non-zero padding:
#(#HoverHelpMorph #LayoutMorph #MenuMorph)

I like it.

The migration would have to be gradual, picking one of the existing 
BoxedMorph subclasses, and either ensuring no use of 'border', and make 
it subclass BoxMorph, or make it subclass of BorderedBoxMorph, making it 
also use 'padding'.

Thanks,

>
>> Am 07.09.2024 um 22:49 schrieb Juan Vuletich<juan at cuis.st>:
>>
>> On 9/6/2024 11:47 AM, ken.dickey--- via Cuis-dev wrote:
>>> And for the rest of us, here is the 3 combined ChangeSets into one.
>>>
>>> I think I have now reconstituted all the code I lost.
>>>
>>> Again, sorry for the lost fileout.
>>>
>>> Please test&  feedback.
>>>
>>> Cheers,
>>> -KenD
>> Hi Ken,
>>
>> I think this is useful. But I'm not really happy with adding the ivar to
>> BoxedMorph. I reviewed the immediate subclasses of BoxedMorph, and on a
>> quick look...
>>
>> Classes where 'padding' makes sense:
>> HoverHelpMorph
>> ImageMorph
>> LabelMorph
>> LayoutMorph
>> MenuMorph
>> PluggableMorph
>> TextParagraphMorph
>> TranscriptMorph
>>
>> Classes where 'padding' doesn't make sense:
>> AutoCompleterMorph
>> DraggingGuideMorph
>> HaloHandleMorph
>> HaloMorph
>> HandMorph
>> InnerPluggableMorph
>> LayoutAdjustingMorph
>> MenuLineMorph
>> PasteUpMorph
>> ProgressBarMorph
>>
>> So, I think it would be better to add PaddedMorph as subclass of
>> BoxedMorph, with ivar 'padding'. Then we could (pehaps gradually) change
>> the superclass of classes where we see the advantage, starting with your
>> code to enable the feature.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> --
>> Juan Vuletich
>> cuis.st
>> github.com/jvuletich
>> researchgate.net/profile/Juan-Vuletich
>> independent.academia.edu/JuanVuletich
>> patents.justia.com/inventor/juan-manuel-vuletich
>> linkedin.com/in/juan-vuletich-75611b3
>> twitter.com/JuanVuletich
>>
>


-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich