[squeak-dev] Re: Preferences with spaces in them
Andreas Raab
andreas.raab at gmx.de
Sun Aug 23 05:51:09 UTC 2009
Ronald Spengler wrote:
> Interesting. While digging around trying to find out what was going on,
Yeah, this stuff ain't pretty. Which is the reason why (in the long
term) I want to get away from hardcoded Preferences and move to pragmas.
The point being that a pragma preference, such as TextMorph
class>>useNewEditors can be discovered by any preference browser/viewer
- there is no reason whatsoever to have preferences in the kernel at
all. A preference is nothing but a user-visible variable so all we need
is to annotate the variables we want to expose.
Plus, it solves a set of issues for preference installation and
initialization. Have a look at the elaborate dance in SHTextStyler80
class>>initializePreferences which is only there because one must inject
preferences into this external entity called Preferences instead of
keeping them in class vars local to the class/packages where they are
needed.
And of course, it gives you an obvious way of changing the preference.
Instead of Preferences enable: #useNewMorphicEditors you simply set the
underlying variable, i.e., TextMorph useNewEditors: true. Which is good
straightforward code that works directly with senders/implementors etc.
Cheers,
- Andreas
> I did stumble across PragmaPreference by printing:
>
> Preferences allPreferenceObjects
>
> ... and searching the resultant text for 'Editors' finding "a
> PragmaPreference#'Use New Editors' nil#'Use New Editors'" in the output.
>
> But the class comment for PragmaPreference:
>
> "Differs from superclass by redirecting all queries to preference provider."
>
> ... didn't help me any, because I didn't know what was meant by
> preference provider. For want of Cmd-Shift-E (thank you! awesome!) I
> just browsed the protocol a bit, looked at the superclass, gave up and
> cried 'halp!'
>
> Maybe I would have grokked this right away had I a better (read:
> passing) grasp of the superclass, but PragmaPreference feels like it
> wants to do something of architectural significance. Maybe move
> preferences off to the actual objects where the behavior is specified,
> instead of a big pile, perhaps?
>
> - Ron, curiously
>
> On Sat, Aug 22, 2009 at 9:50 PM, Andreas Raab <andreas.raab at gmx.de
> <mailto:andreas.raab at gmx.de>> wrote:
>
> Ronald Spengler wrote:
>
> How can I talk to preferences that have spaces in them? I'm
> trying to add a line to my image configuration script that
> enables the Cuis editors automatically.
>
>
> Cmd-Shift-E (Alt-Shift-E) is your friend. Select "Use New Editors",
> press Cmd-Shift-E and the only hit should be TextMorph
> class>>useNewEditors with its companion accessor #useNewEditors:.
>
> (what you are seeing here is a pragma preference which shouldn't be
> manipulated by its user-visible description)
>
> Cheers,
> - Andreas
>
>
> My usual strategy of:
>
> Preferences
> setPreference: #swapMouseButtons toValue: true
>
> ... doesn't seem to work.
>
> When I print:
>
> Preferences setPreference: #'Use New Editors' toValue: true;
> valueOfPreference: #'Use New Editors'
>
> ... I get back nil.
>
> Failing that, I also tried:
>
> Preferences togglePreference: #'Use New Editors'
>
> ... which pops a MNU, so in general I think there's something
> that I'm failing to understand.
>
> Any help is much appreciated.
>
> - Ron
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
More information about the Squeak-dev
mailing list
|