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