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
> 
> 
>         ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
>