[Cuis-dev] LayoutMorph>>adoptWidgetColor:

[Juan Vuletich]

Hi Luciano,

Your reasoning sounds correct to me. Just pushed your change. If someone 
complains, we'll see.

Thanks!

On 2026-06-25 2:30 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> 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 Vuletich
>     www.cuis.st <http://www.cuis.st>
>     github.com/jvuletich <http://github.com/jvuletich>
>     researchgate.net/profile/Juan-Vuletich <http://researchgate.net/profile/Juan-Vuletich>
>     independent.academia.edu/JuanVuletich <http://independent.academia.edu/JuanVuletich>
>     patents.justia.com/inventor/juan-manuel-vuletich <http://patents.justia.com/inventor/juan-manuel-vuletich>
>
>
-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260626/882b62af/attachment.htm>