Now I'm really confused :-(
Scott Wallace
scott.wallace at squeakland.org
Wed Jul 17 22:38:00 UTC 2002
At 2:37 PM -0700 7/17/02, Ned Konz wrote:
> > But since the big event rewrite of autumn 2000, the preference
>> "cmdGesturesEnabled" is no longer being consulted during event
>> dispatch. That's why the menus and halos are not being disabled.
>
>Scott, I'm coming up with a CS to fix this (since I need it too).
Excellent!
>What do we think that cmdGesturesEnabled should suppress?
>
>I'm in favor of suppressing:
>* halos
>* meta-menus
>* world menu(s) (though maybe this should be a separate pref in case
>someone wants to override the world menu)
>
>And I'd like to make the cmdKeysInText not suppress some keys (I was
>thinking about keeping a Preference with the list of valid cmd keys
>in the text).
Yes, I agree on all these.
And yes, I agree that the fact that we wish to disable *some*
command-keys in text, such as those that map into "do it" or "print
it", should not get in the way of honoring conventional text-editing
command keys such as those used for cut, copy, paste, select-all, the
cursor keys, and maybe others such as find and find-again.
So your idea of maintaining somewhere in Preferences (or whatever) a
list of command keys we *will* honor in text (or maybe a list of
those we *won't*) sounds right on.
>Also, why are there "hard coded" prefs? This gets in the way of
>loading themes that change these. I could see having a theme that is
>a "end user" theme.
This was strictly a speed thing, to minimize the price paid for
checking preferences deep within the heart of event dispatch.
Instead of a dictionary lookup, we have an immediate "true" or
"false" return.
But a price paid for that is that these hard-coded preferences are
not user-visible in the Preferences tool. They only change when some
wizard evaluates a call to #disableProgrammerFacilities or
#enableProgrammerFacilities.
And, as you point out, it does complicate the themes thing. There's
no trouble *entering* a theme -- the end-user theme method just would
call #disableProgrammerFacilities -- but the complication comes in
backing out of it; one could automatically call
#enableProgrammerFacilities when installing any *other* theme, I
suppose, but that feels messy.
And the hard-coded preference idea was perhaps a pointless
optimization anyway; maybe these flags should be embodied as normal,
red-blooded Preferences after all.
Cheers,
-- Scott
More information about the Squeak-dev
mailing list
|