Hi David,

After 6 months of Squeak I would say I am a seasoned beginner.

I started with the grey, but in some videos I probably saw it was possible to color the windows and promptly I did it. It is definitely clearer, it lets you jump faster and doubtless between Transcript-Workspace-Browser(s)-Debugger. 

Also, with colors, it is easier to distinguish Squeak world from the rest of your OS.

Squeak development is shocking for the mind of the experienced programmer, in many ways. Colorful windows is one of these way. In unix we have only two colors, one is for the "active / with-cursor" window the other is for all the inactive windows. More or less is the same for macOS and Windows. But Squeak is an OS more than a programming language so I guess it should be not bound to these conventions. 

It is not matter of urgency. But, I would vote definitely to keep colored windows by default. 

If you are a beginner you will be shocked. Let it be, this is not Emacs+Python or Vim+C or AndroidStudio. It is something completely different and you should be shocked right at the beginning ;) 

Opinion of total beginners (so, partially also mine) should be weighted less, because they do not know what is coming. Like opinion of students, let them choose democratically and Calculus would be deleted from any curriculum. :P 

bye
nicola




> On Dec 23, 2019, at 1:59 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> I am sure that both of those preferences will remain.
> 
> I also agree with your view of colorful windows, and I always turn
> this preference on in my image(s). But I recall that this was discussed
> for the 5.2 release, and we had feedback from new users who did
> not like the window coloring. For that reason, we should probably
> keep the preference turned off in the release image.
> 
> But I am not a "new user" any more, so if there are any fresh opinions
> on the subject of colorful windows, please speak up :-)
> 
> Dave
> 
> 
> On Mon, Dec 23, 2019 at 12:29:03AM +0100, Nicola Mingotti wrote:
>> 
>> I am totally 'pro' on reducing the number of preferences.
>> 
>> But I ask you this:
>> 
>> [1] Do not remove the preference to keep different windows in different colors. That is one of the most useful decision you can make IMHO. Why would you color the Browser, Workspace and Debugger in the same way? 
>> 
>> I understand that all grey may seems more a "professional/industrial" interface, but I guess we can leave that aim to Pharo and go on on our way. 
>> 
>> [2] "do not remove the possibility of having larger fonts". 
>> 
>> With high High-DPI Squeak would be unusable out of the Box. 
>> 
>> bye
>> Nicola
>> 
>> 
>> 
>> 
>>> On Dec 20, 2019, at 11:18 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>> 
>>> A preference elimination initiative would be *very* welcome, but
>>> it is something that we should start working on immediately after
>>> the 5.3 release.
>>> 
>>> Preferences are like other bad habits: easy to get into, and
>>> hard to eliminate. So let's all make a New Year's resolution to
>>> lose weight, exercise more, eat healthier food, and get rid of
>>> unnecessary preferences in Squeak.
>>> 
>>> For the current release, I think that we should limit discussion
>>> to specific default preference settings that we might want to
>>> change for the upcoming release.
>>> 
>>> Dave
>>> 
>>> On Fri, Dec 20, 2019 at 12:57:15PM -0800, tim Rowledge wrote:
>>>> We have a *lot* of preferences - in my view way too many - and there should be at least some discussion about the default values we provide for 5.3 
>>>> tl;dr - Too many preferences, too badly organised. reduce, make decisions, simplify.
>>>> 
>>>> I can't imagine I'll hit all of them here but let's try to get something done - 
>>>> 
>>>> Arithmetic 
>>>> Should we have these as preferences? How many people understand enough about Burnikel-Ziegler recursion splits to make it sensible to easily change?
>>>> 
>>>> Compiler
>>>> I claim we are long past the point where enabling block argument assignments or underscore assignment should be a default. Fix your damn code!
>>>> Are we sticking with the EncoderForV3PlusClosures encoder?
>>>> 
>>>> Examples
>>>> These are for the test suite and if possible should be hidden
>>>> 
>>>> Files
>>>> The one entry here relates to the encoding of stdio streams so maybe this category should be renamed?
>>>> 
>>>> Graphics
>>>> Both entries relate to sub-pixel font rendering, so again, rename?
>>>> 
>>>> Morphic
>>>> So. Many. Preferences.
>>>> Surely at least the text edit related ones ought to be removed and kept to the 'editing' section?
>>>> 
>>>> OLPC
>>>> Really?
>>>> 
>>>> TextDiff
>>>> Could be better placed; in Tools?
>>>> 
>>>> Tools
>>>> 'Use unified message labels' What does this do? Is it worth allowing a choice for this sort of thing?
>>>> 
>>>> browsing
>>>> Aargh! More options than 31 flavour ice-cream stores! How many are actually of value?
>>>> 'ignore style if only bold'?
>>>> 'menu button in tool pane' - no actual senders, for example
>>>> 
>>>> colors
>>>> 'Use the new color picker' - is the new color pick not our pick for picking colors? If it still isn't the sensible choice more than 10 years later, maybe we should dump it completely.
>>>> 
>>>> fileout
>>>> are there ever good reasons to not have 24 hr timestamps? For not checking for slips?
>>>> 
>>>> general
>>>> Wow, still more flavours of ice-cream.
>>>> 'Read only mode' - no senders. It's so old there is no timestamp.
>>>> 'Use locale' is there any reason to ever not use it?
>>>> 
>>>> .... and my brain melted at this point.
>>>> 
>>>> 
>>>> 
>>>> tim
>>>> --
>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>> Useful random insult:- Couldn't pour water out of a boot with instructions on the heel.
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>