When you say you want to "get rid of Preferences" I hope you mean just the *implementation* -- e.g., the idea having a global Preferences class with a lot of stuff in it. I hope you agree we need the _functionality_ of preferences.
I agree about Preferences class from a code prettiness / global=bad-design perspective, but one thing I would not want to lose is the global preferences UI. Today, I can get to any preference in under 2 seconds with three quick gestures:
1 - zip the mouse outside of active window. Desktop command keys are now active. 2 - Command+Shift+P. Preferences window opens. 3 - type a few search characters
Also, there are some preferences which are truly global I don't know where you want to put them (like, uh... Desktop Cmd Keys, for example!). We could end up scattering a bunch of truly global preference variables out into various other classes. Is that a lot better?
On Tue, Dec 4, 2012 at 10:06 AM, Frank Shearar frank.shearar@gmail.comwrote:
On 4 December 2012 15:57, Levente Uzonyi leves@elte.hu wrote:
On Tue, 4 Dec 2012, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of ReleaseBuilder to project The Inbox: http://source.squeak.org/inbox/ReleaseBuilder-fbs.78.mcz
==================== Summary ====================
Name: ReleaseBuilder-fbs.78 Author: fbs Time: 4 December 2012, 3:44:56.178 pm UUID: b4603341-7ff0-4a63-938f-160ddfdff273 Ancestors: ReleaseBuilder-fbs.77
4.4 will ship with new network support (including IPv6) _disabled_ by default.
=============== Diff against ReleaseBuilder-fbs.77 ===============
Item was changed: ----- Method: ReleaseBuilderFor4dot4 class>>setPreferences (in category 'private') ----- setPreferences Preferences installBrightWindowColors ; setPreference: #scrollBarsWithoutMenuButton toValue:
true
; setPreference: #swapMouseButtons toValue: true ; setPreference: #annotationPanes toValue: true ; setPreference: #showSplitterHandles toValue: false ; setPreference: #showBoundsInHalo toValue: true ; setPreference: #alternateHandlesLook toValue: false ; setPreference: #roundedMenuCorners toValue: false ;
setPreference: #roundedWindowCorners toValue: false;
setPreference: #enableIpv6 toValue: false.
This won't work, because #enableIPv6 (note that it's not #enableIpv6) is
a
"pragma" preference, so Preferences has no effect on it. The proper way
to
change its value is to evaluate the following:
NetNameResolver enableIPv6: false.
OK. Typo aside, that's rather confusing. "Everything else" sets preferences through Preferences, and the Preference Browser shows the IPv6 preference.
frank
Levente
P.S.: In 4.5 we should get rid of Preferences altogether (this should
have
been done in 4.1 or 4.2 IMHO).
I can't say I'm a fan of random dictionaries containing random symbols, with no way of finding, say, a preference that might differ between the 'ja' and 'en' locales.
frank
On 5 December 2012 19:30, Chris Muller asqueaker@gmail.com wrote:
When you say you want to "get rid of Preferences" I hope you mean just the *implementation* -- e.g., the idea having a global Preferences class with a lot of stuff in it. I hope you agree we need the _functionality_ of preferences.
I agree about Preferences class from a code prettiness / global=bad-design perspective, but one thing I would not want to lose is the global preferences UI. Today, I can get to any preference in under 2 seconds with three quick gestures:
1 - zip the mouse outside of active window. Desktop command keys are now active. 2 - Command+Shift+P. Preferences window opens. 3 - type a few search characters
Also, there are some preferences which are truly global I don't know where you want to put them (like, uh... Desktop Cmd Keys, for example!). We could end up scattering a bunch of truly global preference variables out into various other classes. Is that a lot better?
Modulo "truly global preferences", I would think that a large portion - hopefully almost all - Preferences could be turned into pragma preferences, like the enableIPv6 preference: it appears in the global list, but its definition is strictly local. That also means more easily unloadable (and loadable) packages, that don't need to edit shared structures.
frank
On Tue, Dec 4, 2012 at 10:06 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 4 December 2012 15:57, Levente Uzonyi leves@elte.hu wrote:
On Tue, 4 Dec 2012, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of ReleaseBuilder to project The Inbox: http://source.squeak.org/inbox/ReleaseBuilder-fbs.78.mcz
==================== Summary ====================
Name: ReleaseBuilder-fbs.78 Author: fbs Time: 4 December 2012, 3:44:56.178 pm UUID: b4603341-7ff0-4a63-938f-160ddfdff273 Ancestors: ReleaseBuilder-fbs.77
4.4 will ship with new network support (including IPv6) _disabled_ by default.
=============== Diff against ReleaseBuilder-fbs.77 ===============
Item was changed: ----- Method: ReleaseBuilderFor4dot4 class>>setPreferences (in category 'private') ----- setPreferences Preferences installBrightWindowColors ; setPreference: #scrollBarsWithoutMenuButton toValue: true ; setPreference: #swapMouseButtons toValue: true ; setPreference: #annotationPanes toValue: true ; setPreference: #showSplitterHandles toValue: false ; setPreference: #showBoundsInHalo toValue: true ; setPreference: #alternateHandlesLook toValue: false ; setPreference: #roundedMenuCorners toValue: false ;
setPreference: #roundedWindowCorners toValue: false;
setPreference: #enableIpv6 toValue: false.
This won't work, because #enableIPv6 (note that it's not #enableIpv6) is a "pragma" preference, so Preferences has no effect on it. The proper way to change its value is to evaluate the following:
NetNameResolver enableIPv6: false.
OK. Typo aside, that's rather confusing. "Everything else" sets preferences through Preferences, and the Preference Browser shows the IPv6 preference.
frank
Levente
P.S.: In 4.5 we should get rid of Preferences altogether (this should have been done in 4.1 or 4.2 IMHO).
I can't say I'm a fan of random dictionaries containing random symbols, with no way of finding, say, a preference that might differ between the 'ja' and 'en' locales.
frank
squeak-dev@lists.squeakfoundation.org