Re: [Pharo-dev] default monospaced code font

[btc]

Pavel Krivanek wrote: I started this thread because I tried the fonts and I discovered that something really bad happened to my eyes. Suddenly I had real problems to read the code. Above all it was much harder to me to see borders of keyword messages. Lines started to be much wider and it was harder to see them at once, their structure, blocks etc. Moreover, I had the feeling that code I'm looking at is not Smalltalk :-) I know that it's in my brain and how easy is to change the default font settings. I have nothing against it if it will make Pharo more friendlier to newcomers and I the new icons are good. I only wanted to know if others the same brain disability :-) It's interesting that I edit Smalltalk in text files with monospaced font quite often. To try the settings from the new theme eval this: SourceCodeProRegular new install. OpenSansRegular new install. FreeTypeFontProvider current updateFromSystem. SourceCodeFonts setSourceCodeFonts: 10. -- Pavel Thanks Pavel. I don't have a strong philosophical opinion either way, so its good to have a concrete example to compare.  Monospacing aside, I like the proposed font.  It is strong and very readable.  However I think actually you need to compare using "setSourceCodeFonts: 9." since otherwise you only get 80% of the line length with the proposed font, which would be a point against your specific example above. I generally advocate making things more attractive to newcomers who come for a taste-test. After all you do want those taste-test newcomers to stick around to grow the community.  However this needs to be balanced against the burden for the older community.  So I have a new related proposal based on three points: 1. Emotive issues such a familiar font-spacing do affect people's decision making.  So it is good to eliminate these emotive blockers so they don't unreasonably deter people before they discover the technical advantages of Smalltalk.  2. Jimmy makes a good point that: "A beginner will often stay with what they start with for a very long time."  Yet once newcomers get familiar with Smalltalk, you likely have them hooked.  Then fonts are less of an issue.  So while you want to cater to a newcomers (possible) preference for monospaced fonts, you want to encourage them to adopt our community standard for proportional fonts.  3. Eliot made the point that other languages are "orthogonal to fonts."   This made me consider that any community might standardize on a particular font, but the developers of the C stdlib can use one font, while the developers of GTK and python can each use different fonts, while the developers of an end-user application using all those can use yet another font.  In contrast, "in practice" Pharo is restricted to only one font across a broad range of different packages.  So that got me wondering... could it be useful for different packages(or categories) be able to specify their standard font.   While the disadvantage is increasing the size of the task, but the advantages are: a. Infrastructure packages delivered with the image where the existing community do a lot of work remains proportional with having the fiddle with any preference systems. b. Newcomers don't have much to do with editing that infrastructure, so they are unaffected by this.  By the time they consider changing things, they are no longer newcomers and btw you already have them hooked if they are even considering updating that code. c. Newcomers get the make the CHOICE for their OWN code.  This choice eliminates proportional/monospace as an emotive "reason" to reject Smalltalk. d. Over time as newcomers debug their code, they are inherently exposed to the proportional font of the infrastructure code.  From this they become familiar with and subsequently more comfortable with proportional fonts, and over time hopefully tend to align with the general community.  Regarding the added complexity of different fonts per package.  Previously raised was the idea that packages have custom lists of disabled code-critics, so perhaps it links in with that part of the UI. anyway, just brainstorming... there are probably lots of holes in that proposal I haven't stopped to think about.  Have fun chopping it up. cheers -ben