<div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Shout wants to be the only mechanism that governs text attributes in a (pluggable) text morph. It does not keep track of its own additions or anything that has been there before. You cannot even combine two different kinds of "Shout stylers" if you would want to. Thus, any manual changes to text attributes will be discarded once Shout decides to re-style the text contents again. That is why CMD-7 does not work as expected if a text morph has a styler and hence Shout styling enabled.<div><br></div><div>We decided to put all Shout-styling properties into the UI themes because code styling is closely related to all other visual properties in the system. For example, the code as to look different in "Solarized" than it does in "Monokai" or "Default Squeak":</div><div><br></div><div><img src="cid:f021d6e6-c978-4fd6-bfa8-125a4b9cfc34" width="auto"></img></div><div><br></div><div>If you want to write a tool or application that DOES NOT comply with UI themes, you might encounter several barriers at this moment. However, there is #canApplyUserInterfaceTheme implemented in Morph to start thinking about this challenge. You can set the property #noUserInterfaceTheme to avoid UI-theme application. This suggests a bigger refactoring I should approach. All calls to #setDefaultParameters might need to happen through #applyUserInterfaceTheme, which me might want to guard for Morphs, for example. Let me think about that.</div><div><br></div><div>Anyway: Managing side effects and state in an image-based object system remains challenging. :-)</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 26.03.2018 20:22:36 schrieb tim Rowledge <tim@rowledge.org>:</p><br><br>> On 25-03-2018, at 8:52 PM, Chris Muller <asqueaker@gmail.com> wrote:<br>> <br>>> Maybe even per-editor instance preferences. Inherit the global as a default but allow changing at need. Need a UI to make it useful. Actually we really need some big improvements to the prefs/settings/style/font/colour stuff for editors anyway.<br>> <br>> UserInterfaceTheme in the image does that.  We did it in summer of<br>> 2016, the color themes work pretty well ever since.<br><br>I was thinking more of the UI for changing text styles/font/colours within editors etc. Marcel's answer about having properties within the themes that could cover these sounds interesting.<br><br>I've just noticed an extra bit of complication when thinking about this wrt Shout colouring - just try cmd-7 with some selected text in a code view! Even in a comment...<br><br>tim<br>--<br>tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>Diagnostics are the programs that run when nothing else will.<br><br><br><br></asqueaker@gmail.com>
                        </blockquote></div>