[squeak-dev] How should one implement a custom window color for a custom window?
asqueaker at gmail.com
Mon Sep 18 00:09:22 UTC 2017
That's true. One goal of the design was to provide access to a
first-class Theme object, without needing to either write, nor see,
that extra level of indirection in the code.
myMorph userInterfaceTheme color
(myMorph userInterfaceTheme propertyNamed: #color)
The latter becomes a wordy and repetitious (not to mention, the extra
parenthesis), a lot to ask clients to sprinkle throughout their code.
I don't see the example "never being GC'd" as being related to the
UserInterfaceTheme implementation. I may be missing your question but
-- if an explorer is opened [substitute with any case of: user still
needs the object], the object would not be GC'd, regardless from which
code it was opened.
On Sun, Sep 17, 2017 at 7:02 AM, Stéphane Rollandin
<lecteur at zogotounga.net> wrote:
> Nice informative post, thanks Marcel.
> I think I see something fragile in the implementation though: each
> #userInterfaceTheme send must absolutely be followed by another selector,
> else the relevant stacked object (in the scope inst. var. of the theme) will
> not be popped at the proper moment.
> In other words, a line of code as simple as
> Morph new userInterfaceTheme explore
> may break things in potentially ugly ways; for one thing, even if further
> scope push/pop work properly, the Morph instanciated by the above code will
> never be GCed...
> Does that make sense?
More information about the Squeak-dev