[Cuis-dev] #color: message not honored for button in a SystemWindow

[Gerald Klix]

On 10/19/21 3:33 PM, Juan Vuletich via Cuis-dev wrote:
> On 10/17/2021 6:06 AM, Gerald Klix via Cuis-dev wrote:
>>
>>
>> On 10/17/21 9:51 AM, Hilaire Fernandes via Cuis-dev wrote:
>>> Hi,
>>>
>>> Something annoying I don't understand why:
>>>
>>>      row addMorph: ((PluggableButtonMorph         model: self action: 
>>> #cancel         label: 'Cancel' translated) *color: Theme current 
>>> cancelButton*).
>>>
>>> the color message is not honored, color remains to the default value.
>>>
>>> Afterward, from an inspector the #color: message is honored.
>>>
>>> Is it related to the fact these morph are then added to a SystemWindow?
>> Absolutely!
>>
>> Take a look at SystemWindow class>>#open:label:, which sends
>> #openInWorld to the newly created system window.
>> SystemWindow>>#openInWorld sends #widgetsColor:
>> to itself, before sending #openInWorld to super.
>> SystemWindow>>#widgetsColor: sends #adoptWidgetsColor:
>> to self, which recurses through the morph hierarchy
>> to set all widgets' colors to the system window's
>> color. To make things a bit "more complicated"
>> PluggableButtonMorph overrides #adoptWidgetsColor:
>> to mix the system window's color with the theme's
>> button color.
>> Cuis goes through this complicated rigamarole,
>> to provide nice colored browser windows,
>> which are still themeable.
>>
>> The net effect is:
>> #color: is honored and than rudely written
>> over by the system window. I suggest sub-classing
>> PluggableButtonMorph and overriding #adoptWidgetsColor:
>> according to your needs and taste.
>>
>>
>> HTH,
>>
>> Gerald
> 
> I'm not really happy with that complexity. If anybody suggest a better 
> alternative than these #widgetsColor: and #adoptWidgetsColor: , it would 
> be nice.
If these requirements are still valid:
   - SystemWindows for browsers should be color-coded
     for the browser's type
   - Every (pluggable) widget should be themeable
then I see no other way to satisfy these requirements,
than to traverse the morph hierarchy.
A great deal of the "perceived" complexity is caused
by the fact that the sends of the method that does
the work (#adoptWidgetsColor:) is hidden behind
a long chain of other message sends:
#open: -> #open:label: -> #widgetsColor: -> #adoptWidgetsColor:

OTH, I would like to add still another method to separate
the recursion in Morph>>#adoptWidgetsColor: and
the actual color change.

Side note:
There is an unused flag in LayoutMorph
(doAdoptWidgetsColor), which is set to true
in LayoutMorph>>#initialize and than AFAIK never
changed.


If all else fails, writing some documentation in SystemWindow's
class comment may help. Even a https-link to this e-mail
thread would be useful and easy to do.


Some general thoughts:

Concerning these requirements, I find the color
coded browser windows a bit too colorful and distracting,
therefore I use a single color scheme for Haver.
Alas the taskbar "icons" are not very useful
without the color coded browser windows,
because they are hard to to distinguish
without color (at least for me).
I thought about having a one-color
theme, but render the taskbar "icons"
with color, but that would mean adding
more complications to an already
complicated algorithm/program.
I would also like to have a bit of color.
Maybe shown the browser's color at the window's
upper left corner. Needless to say,
that this again would add "complexity".
Another one from my huge collections of
brain-farts (aka. ideas) is to temporarily
switch to color coded windows if the user
presses a yet to choose hot-key, like
the mouse-cursor highlighting in Windows
when you press the control key...

In a nutshell:
Don't make hasty changes, the aforementioned
requirements have a valid rationale.


Just my 0.02€,

Gerald