Squeak 5.1 PreferenceBrowser notes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Squeak 5.1 PreferenceBrowser notes

timrowledge
I actually sat and read through, and tried, all the preferences. It was not a lot of fun. Here are some notes resulting from that marathon of pain.

Basic points
========

Ridiculous mix of upper and lower cased and camel-cased preference names. Some with spaces, some not. Accompanying help text often needs spelling, grammar or factual fixes.
The 'help' button window refers to a non-existent 'theme...' button. And has mis-spelllings.
In general we have an insane number of preferences that seem to do nothing interesting . Probably time to get rid of a lot of them and simplify life.

Specific items, with often snarky commentary.
=============================

block assignments - should not be allowed

underscore assignments  - should not be allowed; see Cuis for a way to do it right.

Examples - why are they in the tool? Several appear to be unused anyway

subpixel rendering - not able to see any difference; is it actually in use?

auto-enclose - doesn't match capability with autoEnclose. See TextEditor>>dispatchOnKeyboardEvent: Also, one has char as arg, other has event. Yuck!

highlight hovered row in lists - seems wrong to have the preference in PluggableListMorph but used in just two classes that are not related.

'Menu request updates list/tree selection' help text is gibberish

'Use new style balloon morphs' why bother offering the choice instead of dropping the old ones?

Browse with drag'n'drop - does this need to be a pref?

syntaxHighlightingAsYouType - none of th three seem to have any users

Use the new color-picker - is this of any use?

Corner Grip * - ditto

Flaps - are they still in there?

Thorough senders - dump it

automaticPlatformSettings - what?

modalColorPickers - seems pointless

readOnlyMode - no usages?

alternateHandlesLook - why?

biggerHandles - why? has some interaction with tinyDisplay/bigDisplay

haloTransitions - I don't think so

magic/maintain/mouseOver-Halos - what?

generally halo stuff seems to have an insane number of preferences that are not used.

keyboard duplicate/swap stuff - way too complex and poorly explained

simpleMenus - doesn't really have much effect

timeStampsInMenuTitles - can't see what it is for

menuBorderWidth - doesn't actually seem to relate to menus at all

menuTitleBorderWidth - ditto

- in fact none of the menuXX items seem to be used for menus

Show wrap border in code panes & Wrap border limit - why in 'performance' and what are they supposed to be for?

alternativeButtonsInScrollbars - any use?

too many scrollbar options. must be a better way to make such choices, or actually decide on something and stick to it.

inlineServicesInMenu - comment makes no sense.
- do we still need the preferences if we always have services?

'Offer native fonts' only works with an apparently unused set of StrikeFont code (#fromUser: etc) and the code even breaks on linux since there are no truetype fonts (on my machine at least) Thuse the list of fonts is nil and the TTFileDescription class>>frontFromUser:allowKeyboard: code breaks.

'Selections may shrink' - is there any case where that would not be true?

Font choosing
=========
not part of preferencebrowser, which seems odd.
appearance->systemfonts menu seems to not be matched to the themes fonts stuff? Preferences class>>restoreDefaultFont probably needs to use the theme data.
#setDemoFonts likely simialr, and a 'return to normal' is needed too.
'Offer native fonts' only works with an apparently unused set of StrikeFont code (#fromUser: etc) and the code even breaks on linux since there are no truetype fonts (on my machine at least) Thuse the list of fonts is nil and the TTFileDescription class>>frontFromUser:allowKeyboard: code breaks.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Spell checkers at maximum!  Fire!



Reply | Threaded
Open this post in threaded view
|

Re: Squeak 5.1 PreferenceBrowser notes

Chris Muller-3
Hi Tim, yes, it is known that Preferences has "evolved" over time, and
one of the areas I want to clean up, and I think Marcel and others
too.  I posted my Preferences requirements and goals for what I wanted
to accomplish in the refactor earlier this year.  It didn't happen
this release, but something possibly for the next.  Marcel has already
collapsed several preferences into the new Theming architecture,
probably some more can be next release as well, and some of the ones
you mentioned could too.

I think you have a pretty good list, but we will use a thoughtful and
logical approach and not a snarky one for determining the fate of each
and every Preference.  Preferences are supposed to resolve our
differences, not create them.

re: autoEnclose -- Marcel and I spared the squeak-dev list an
excruciatingly detailed discussion about autoEnclose, taking into
account multiple requirements, editing styles, and keyboard layouts.
A ton of thought and discussion went into it with the goal of
maximizing the UX and achieve as many use-case combinations as we
could.

Best,
  Chris

On Thu, Aug 11, 2016 at 1:24 PM, tim Rowledge <[hidden email]> wrote:

> I actually sat and read through, and tried, all the preferences. It was not a lot of fun. Here are some notes resulting from that marathon of pain.
>
> Basic points
> ========
>
> Ridiculous mix of upper and lower cased and camel-cased preference names. Some with spaces, some not. Accompanying help text often needs spelling, grammar or factual fixes.
> The 'help' button window refers to a non-existent 'theme...' button. And has mis-spelllings.
> In general we have an insane number of preferences that seem to do nothing interesting . Probably time to get rid of a lot of them and simplify life.
>
> Specific items, with often snarky commentary.
> =============================
>
> block assignments - should not be allowed
>
> underscore assignments  - should not be allowed; see Cuis for a way to do it right.
>
> Examples - why are they in the tool? Several appear to be unused anyway
>
> subpixel rendering - not able to see any difference; is it actually in use?
>
> auto-enclose - doesn't match capability with autoEnclose. See TextEditor>>dispatchOnKeyboardEvent: Also, one has char as arg, other has event. Yuck!
>
> highlight hovered row in lists - seems wrong to have the preference in PluggableListMorph but used in just two classes that are not related.
>
> 'Menu request updates list/tree selection' help text is gibberish
>
> 'Use new style balloon morphs' why bother offering the choice instead of dropping the old ones?
>
> Browse with drag'n'drop - does this need to be a pref?
>
> syntaxHighlightingAsYouType - none of th three seem to have any users
>
> Use the new color-picker - is this of any use?
>
> Corner Grip * - ditto
>
> Flaps - are they still in there?
>
> Thorough senders - dump it
>
> automaticPlatformSettings - what?
>
> modalColorPickers - seems pointless
>
> readOnlyMode - no usages?
>
> alternateHandlesLook - why?
>
> biggerHandles - why? has some interaction with tinyDisplay/bigDisplay
>
> haloTransitions - I don't think so
>
> magic/maintain/mouseOver-Halos - what?
>
> generally halo stuff seems to have an insane number of preferences that are not used.
>
> keyboard duplicate/swap stuff - way too complex and poorly explained
>
> simpleMenus - doesn't really have much effect
>
> timeStampsInMenuTitles - can't see what it is for
>
> menuBorderWidth - doesn't actually seem to relate to menus at all
>
> menuTitleBorderWidth - ditto
>
> - in fact none of the menuXX items seem to be used for menus
>
> Show wrap border in code panes & Wrap border limit - why in 'performance' and what are they supposed to be for?
>
> alternativeButtonsInScrollbars - any use?
>
> too many scrollbar options. must be a better way to make such choices, or actually decide on something and stick to it.
>
> inlineServicesInMenu - comment makes no sense.
> - do we still need the preferences if we always have services?
>
> 'Offer native fonts' only works with an apparently unused set of StrikeFont code (#fromUser: etc) and the code even breaks on linux since there are no truetype fonts (on my machine at least) Thuse the list of fonts is nil and the TTFileDescription class>>frontFromUser:allowKeyboard: code breaks.
>
> 'Selections may shrink' - is there any case where that would not be true?
>
> Font choosing
> =========
> not part of preferencebrowser, which seems odd.
> appearance->systemfonts menu seems to not be matched to the themes fonts stuff? Preferences class>>restoreDefaultFont probably needs to use the theme data.
> #setDemoFonts likely simialr, and a 'return to normal' is needed too.
> 'Offer native fonts' only works with an apparently unused set of StrikeFont code (#fromUser: etc) and the code even breaks on linux since there are no truetype fonts (on my machine at least) Thuse the list of fonts is nil and the TTFileDescription class>>frontFromUser:allowKeyboard: code breaks.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Spell checkers at maximum!  Fire!
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 5.1 PreferenceBrowser notes

timrowledge

> On 11-08-2016, at 12:47 PM, Chris Muller <[hidden email]> wrote:
> I think you have a pretty good list, but we will use a thoughtful and
> logical approach and not a snarky one for determining the fate of each
> and every Preference.  

Snarky notes are better than no notes I suspect. At least it is a flag to salute. And the major point - that we have a rather tangled mess of confusion that needs pruning and copy-editing - is valid whether pointed or polite. I just wish I’d had time to do some thing more practically useful before code-freeze.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
World Ends at Ten! Pictures at 11 on Fox News!



Reply | Threaded
Open this post in threaded view
|

Re: Squeak 5.1 PreferenceBrowser notes

marcel.taeumel
tim Rowledge wrote
> On 11-08-2016, at 12:47 PM, Chris Muller <[hidden email]> wrote:
> I think you have a pretty good list, but we will use a thoughtful and
> logical approach and not a snarky one for determining the fate of each
> and every Preference.  

Snarky notes are better than no notes I suspect. At least it is a flag to salute. And the major point - that we have a rather tangled mess of confusion that needs pruning and copy-editing - is valid whether pointed or polite. I just wish I’d had time to do some thing more practically useful before code-freeze.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
World Ends at Ten! Pictures at 11 on Fox News!
Hey Tim,

there surely will be another release. ;-)

Yeah, for my way of writing source code, #autoEnclose is kind of cumbersome. I disable that and rather work with #encloseSelection, which I learned to love from OCompletion. :-) Still, there are two buglettes in #encloseSelection, namely hitting [9] on a German keyboard under Windows on a selection or the fact that I cannot enclose a selection with single quotes. Anyway, #encloseSelection circumvents the disability of German Windows keyboards to hit the usual keyboard shortcuts to enclose a selection. Awww, this beautiful [AltGr]-Key ... ^___^

Best,
Marcel