[Cuis-dev] LayoutMorph>>adoptWidgetColor:

[Luciano Notarfrancesco]

I've been experimenting a bit and the attached change set seems to solve my
problem. But I'm not sure if it breaks anyone elses code. The difference is
1) LayoutMorphs are initialized with color transparent instead of theme
default window color; 2) if doAdoptWidgetColor is false, it does nothing
(as opposed to setting the color to transparent). This way, unless
doAdoptWidgetColor is true, the colors you set are never changed
automatically. It seems to not make any difference in the way everything
looks with the default theme or with my dark theme, but does it make sense
for everyone? Or people (or people's already written code) expect the
default color of LayoutMorphs to be the theme default window color?

On Tue, Jun 23, 2026 at 1:30 AM Juan Vuletich <juan at cuis.st> wrote:

> Hi Luciano,
> On 2026-06-22 5:10 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> I still find the adoptWidgetColor mechanism confusing. It often makes
> colors change in unexpected ways.
>
> Yes. It is crap.
>
>
> Here’s an example. I’d like to explicitly set a color for a layout morph
> with color:, but how can I do that without the color being later replaced
> here?
>
> LayoutMorph>>adoptWidgetsColor: paneColor
>     super adoptWidgetsColor: paneColor.
>     adoptsWidgetsColor
>         ifTrue: [ self color: (Theme current buttonColorFrom: color) ]
>         ifFalse: [ self color: `Color transparent` ]
>
> I’d like to make this simpler, not more complicated by adding yet another
> case. Eg, I wouldn’t want to change the doAdoptWidgetColor ivar into a
> colorAdoptionPolicy to cover my use case, I’d rather remove it completly
> and simplify it if that was possible.
>
> Agreed!
>
> I’m the only one who thinks we should change this behaviour? How should we
> change it? Or perhaps there’s already a way to get the behaviour I want
> without changing anything?
>
> Thanks,
> Luciano
>
> No, we should find a better way.
>
> A long time ago we added UI Themes to Cuis. For this to be flexible and
> nice, we want to support 'external' definition of base color for each kind
> of tool, and the various derived colors for each widget. At that time, I
> came up with #adoptWidgetColor: It was not a good solution. We should find
> a better one.
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260626/dc7d0432/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8027-adoptWidgetColorTweak-LucianoEstebanNotarfrancesco-2026Jun25-23h42m-len.001.cs.st
Type: application/octet-stream
Size: 431 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260626/dc7d0432/attachment.obj>