<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Chris, hi Tim, hi all,<div><br></div><div>yes, it would be interesting to find such concepts (or properties?) that can positively affect the complexity of a theme's implementation. Here, "#isDark" might only be the first of several to discover. Also, the uses of such properties might also be manifold. For example, the inversion of color saturation (or brightness) could be a good start to think about it.</div><div><br></div><div>At the moment, I try to reduce code duplication within a single theme (class) through UserInterfaceTheme >> #derive:for:from:at:. Yet, it is often difficult to decide from which property to derive another property. For the resize grips, I just picked a window's border color as reference. Looks okay to me.</div><div><br></div><div>This "isDark" proposal addresses a higher-level reuse than what #derive: can provide right now. I like that. Still, I am not so sure whether the theme designer (person) could benefit from such a mechanism in the long term. There, I see more value in an interactive color-picker-like tool than in improving the implementation details of a UserInterfaceTheme subclass.</div><div><br></div><div>Finally, I want to point out that -- for the long term -- I want to look for a better way to manage theme instances and treat the class-level-initalization persistance thingy as one of maybe many (generated) serialization formats for themes. The current (manual) class serialization has been a good start so far. For us theme designers and as a good integration with ReleaseBuilder and Monticello (or code versioning).</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 05.01.2019 00:13:45 schrieb tim Rowledge <tim@rowledge.org>:</p><div style="font-family:Arial,Helvetica,sans-serif"><br><br>> On 2019-01-04, at 2:39 PM, Chris Muller <asqueaker@gmail.com> wrote:<br>> <br>> Hi Marcel,<br>> <br>> As we derive colors from other colors, it seems like the "Dark" themes will generally be consistently the inverse of the normal daytime themes.  Like, in this example,  AbstractResizerMorph>>#handleColor defaults to "muchDarker". <br><br>For themes where there is a need for darker or lighter depending on the intent of the theme, rather than being specific in a confusing manner  - ie actually using #darker etc - might it help to refer to something on a different axis? For example #stronger & #softer could be used in a bright or a dark theme to refer to the progression of colour without any reliance on the specific theme needs. Sort of an abstraction of intent. Give a theme a collection of colours and set the middle as 'normal'. Or have an algorithm specific to the theme. Or both, depending on the nice new Chronology state :-)<br><br><br>tim<br>--<br>tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>Useful Latin Phrases:- Romani quidem artem amatoriam invenerunt. = You know, the Romans invented the art of love.<br><br><br><br></asqueaker@gmail.com></div></blockquote></div>