Hi Tim,
I am sorry that the core mechanism of the User Interface Themes confuses you. :) The idea of application-specific UI properties, such as window colors, kind of overlaps/interferes with the idea of general widget theming.
If you want to work around the UI theming to provide a window color for your tool, just implement #windowColorToUse. If not, just implement #defaultWindowColor like all other tools in the system do. Try the implementors tool to verify. :-)
It is not that difficult. You already found Model >> #windowColorToUse. Now you can use the Squeak's implementors tool to browse implementors of all the symbols you can find in that method: #( useColorfulWindows customWindowColor defaultWindowColor uniformWindowColor). I suppose that that journey ends after a few minutes when you discover:
Best, Marcel Am 16.09.2017 02:00:18 schrieb tim Rowledge tim@rowledge.org: A couple of months back Eliot asked about this and I have a few minutes to spend to maybe fix it.
I notice that Model>windowColorToUse sends #customWindowColor, which is not implemented. Which would seemingly lead us to expect a debugger but I see some very… interesting code in UserInterfaceTheme where a dNU: is caught and Very Odd Things are done. Ten out of ten for creative and intriguing code, minus several million for completely obscured intent.
At the least it would be nice to have an implementation *somewhere* that explains what is being done, why, and maybe even how we can move to a simpler scheme.
Related things I noticed - EToys-Squeakland adds Object, StringHolder & TranscriptStream class > windowColorSpecification which seem to be in need of removal. PreferencesPanel class>windowColorSpecification is seemingly in need of the chop WindowColorRegistry, the only sender of windowColorSpecification, is in the deprecated categories, though yes, i nthe 5.1 deprecation pile so maybe is has to stay for now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WK: Write to Keyboard
