<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Pavel Krivanek wrote:
<blockquote
 cite="mid:CAHN2FzcTm0SAbgLNcfQgBuyMroKoOe68=gmaMziTYw13tpyO7Q@mail.gmail.com"
 type="cite"><!----><br>
  <pre wrap="">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

  </pre>
</blockquote>
Thanks Pavel. I don't have a strong philosophical opinion either way,
so its good to have a concrete example to compare.  <br>
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.<br>
<br>
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:<br>
<br>
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.  <br>
<br>
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.  <br>
<br>
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.  <br>
<br>
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:<br>
<br>
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.<br>
<br>
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.<br>
<br>
c. Newcomers get the make the CHOICE for their OWN code.  This choice
eliminates proportional/monospace as an emotive "reason" to reject
Smalltalk.<br>
<br>
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.  <br>
<br>
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.
<br>
<br>
anyway, just brainstorming... there are probably lots of holes in that
proposal I haven't stopped to think about.  Have fun chopping it up.<br>
cheers -ben<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>