AW: [squeak-dev] Squeak 5.1 PreferenceBrowser notes

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

AW: [squeak-dev] Squeak 5.1 PreferenceBrowser notes

Herbert König
Hi, 
Flaps are the only way to move a Moroh from one Project to the next. Well the only convenient way i know of.
Please keep them. 

Cheers, 
Herbert


-------- Ursprüngliche Nachricht --------
Von: tim Rowledge
Datum:11.08.2016 20:24 (GMT+01:00)
An: The general-purpose Squeak developers list
Betreff: [squeak-dev] Squeak 5.1 PreferenceBrowser notes

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: AW: [squeak-dev] Squeak 5.1 PreferenceBrowser notes

marcel.taeumel
Herbert König wrote
Hi, 
Flaps are the only way to move a Moroh from one Project to the next. Well the only convenient way i know of.
Please keep them. 

Cheers, 
Herbert

<div>-------- Ursprüngliche Nachricht --------</div><div>Von: tim Rowledge <[hidden email]> </div><div>Datum:11.08.2016  20:24  (GMT+01:00) </div><div>An: The general-purpose Squeak developers list <[hidden email]> </div><div>Betreff: [squeak-dev] Squeak 5.1 PreferenceBrowser notes </div><div>
</div>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!
Hey Herbert,

sure, flaps remain. When I poked around in some flaps code, I noticed big refactoring potential. :) The way global and project-local flaps are initialized, updated, shown, hidden, ... kind of quirky and error-prone.

Best,
Marcel