<div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Hi Tim,<div class="mb_sig"></div>
<div><br></div><div>if you want to bench the lookup in your system, take a look at UserInterfaceThemeTestObject >> #benchLookup.</div><div><br></div><div>Note that Squeak's current widgets got changed to only use themes in their initialization code. It is not a regular lookup to, for example, draw a button.</div><div><br></div><div>Best,</div><div>Marcel</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 19.09.2017 06:21:42 schrieb Chris Muller <asqueaker@gmail.com>:</p>With all due respect, Tim, this comment reads like your "reaction".<br>It doesn't leave the reader with any more clarity than from simply<br>reading the code. We (myself, Marcel and Hannes) spent a good part of<br>a year critically thinking and discussing Themeing in Squeak to arrive<br>at this balanced and effective design. Only a few minutes tracing the<br>sparse amount of code and thinking about the requirements is needed to<br>understand and appreciate it.<br><br>You've mentioned the "dreadful state" of the wiki documentation<br>before, and Hannes provided the link to the existing page about<br>UserInterfaceTheme. Your contributions are better appreciated by working<br>with original authors and using the Inbox first.<br><br>Thanks.<br><br>On Mon, Sep 18, 2017 at 6:45 PM, <commits@source.squeak.org> wrote:<br>> tim Rowledge uploaded a new version of System to project The Trunk:<br>> http://source.squeak.org/trunk/System-tpr.962.mcz<br>><br>> ==================== Summary ====================<br>><br>> Name: System-tpr.962<br>> Author: tpr<br>> Time: 18 September 2017, 4:45:22.01173 pm<br>> UUID: e1c54891-6fa2-45fd-9acb-58c76815aa62<br>> Ancestors: System-dtl.961<br>><br>> Add and expand some comments that should help to explain UserInterfaceTheme for future readers<br>><br>> =============== Diff against System-dtl.961 ===============<br>><br>> Item was changed:<br>> ----- Method: UserInterfaceTheme>>doesNotUnderstand: (in category 'lookup') -----<br>> + doesNotUnderstand: aMessage<br>> + "In order to be able to use a UserInterfaceTheme as a container of fairly arbitrary properties whilst making it seem like we are sending regular messages as a way of accessing those properties we can handle the dNU: and check the not understood message name against our property list. This is clever, devious, interesting and may confuse users until they get to see an explanation like this"<br>> + "Answer nil or a value for the property specified by aMessage's #selector. Searching for the property proceeds by<br>> + a) searching my dictionary for a key made up of an Association with a key of the class of the 'client' and a value of the message name. For example SimpleButtonMorph->borderColor<br>> + b) searching again for a key made from the superclass(es) of the client - e.g. RectangleMorph->borderColor and then if required BorderedMorph->borderColor etc.<br>> + c) if there is a linked theme, search it in the same manner.<br>> +<br>> + As an extreme example, consider a basic theme with a linked theme specifically for buttons.<br>> + mySimpleButtonMorph borderColor<br>> + would search the basic theme for SimpleButtonMorph->borderColor, the superclass equivalents as in b) above, then search the linked theme for SimpleButtonMorph->borderColor and, we hope, find something meaningful"<br>> - doesNotUnderstand: aMessage<br>> - "Answer whether I have, or inherit, a value for the visual-attribute specified by aMessage's #selector."<br>><br>> aMessage numArgs > 0 ifTrue: [^ super doesNotUnderstand: aMessage].<br>> scope isEmpty ifTrue: [^ super doesNotUnderstand: aMessage].<br>><br>> ^ [self get: scope top class -> aMessage selector]<br>> ensure: [scope pop]!<br>><br>> Item was changed:<br>> ----- Method: UserInterfaceTheme>>get: (in category 'private') -----<br>> get: keyObject<br>> + "keyObject is intended to be an Association. We have two lookup strategies: 1) along the superclass chain *of the client*, 2) via a linked theme. Evaluate the result because there can be message sends stored or blocks."<br>> - "keyObject is intended to be an Association. We have two lookup strategies: 1) along the superclass chain, 2) via a linke theme. Evaluate the result because there can be message sends stored or blocks."<br>><br>> | k |<br>> properties<br>> at: keyObject<br>> ifPresent: [:prop | ^ prop value].<br>><br>> keyObject isVariableBinding "simple key objects"<br>> ifFalse: [^ self getViaLink: keyObject].<br>><br>> k := keyObject key.<br>> (self getViaSuperclasses: keyObject)<br>> ifNotNil: [:prop | ^ prop].<br>><br>> keyObject key: k. "restore"<br>> ^ self getViaLink: keyObject!<br>><br>> Item was changed:<br>> ----- Method: UserInterfaceTheme>>getViaLink: (in category 'private') -----<br>> getViaLink: keyObject<br>> + "keyObject is intended to be an Association.<br>> + If there is a linked theme, see if it has the relevant property available"<br>> - "keyObject is intended to be an Association"<br>><br>> ^ next ifNotNil: [next get: keyObject]!<br>><br>> Item was changed:<br>> ----- Method: UserInterfaceTheme>>getViaSuperclasses: (in category 'private') -----<br>> getViaSuperclasses: keyObject<br>> + "keyObject is intended to be an Association.<br>> + Find the superclass of the key of the keyObject (which will initially be the client's class) and make a new keyObject using that and the original message name, then try searching for that."<br>> - "keyObject is intended to be an Association"<br>><br>> "We know we're the only referencer of keyObject. Update it rather than create new ones, for performance reasons."<br>> keyObject key: keyObject key superclass.<br>><br>> keyObject key ifNil: [^ nil].<br>><br>> properties<br>> at: keyObject<br>> ifPresent: [:prop | ^ prop value].<br>><br>> ^ self getViaSuperclasses: keyObject!<br>><br>><br><br></commits@source.squeak.org>
</blockquote></div>