- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] default monospaced code font

by Esteban Lorenzano

On Oct 15, 2013, at 5:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 8:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Oct 15, 2013, at 4:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 15 Oct 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> except that it is not accurate :) > >> > >> - with a monospace you can have bolds and italic without problems (it is a decent one)... and you also can play with sizes (for example, for comments) > >> - when you copy&paste you will lose part of your formatting no matter if you have a fixed font or a proportional one (is not true that you lose all of them... in fact I usually do not lose any) > > > > Sorry, but there are no sensible arguments in favour of a monospaced font. It is just not needed (in Smalltalk). Another way to look at it is: 99.99 % of the world use proportional fonts. > > > > BTW, I think whoever made this 'decision' knew it would be _very_ hard to get this passed ;-) > > > > Maybe we should switch to C/Java/Javascript syntax so that we do not scare newcomers ? Sorry, I could not resist. > not taken. > and non sense. > idea is to welcome newcomers, not to became another language. > Now... if font is *part* of the language, we could be talking about the same. But since it is not, then we are comparing apples with tomatoes. > > Smalltalk is much more than a language. It is also a class library, an incremental/interactive development environment, a set of tools, a number of graphics systems, a system for manipulating multiple media, and so on. Part of that is an aesthetic, especially when applied to the primary communications medium in the sytsem, text. > > So the apples with tomatoes "critique" is baloney. > > I can say that no, 99% of the world do not use proportional fonts... every other programing environment uses monospaced fonts. > yeah, I know "we are different"... but we still code. Ah, no, sorry... we "manipulate objects", but that looks really close to coding for me. > > That's wrong. Few languages have been used to implement their own display system. Development "in" those languages is in fact, merely editing in whatever toolset the programmer chooses and not an integral part of the language at all. So most other languages neither use, nor don't use proportional or mono-spaced font. They are orthogonal to fonts. They are purely sequences of characters. Programmers impose formatting conventions to make texts that denote programs in those languages readable. But those languages are font-agnostic, and the conventions not integral parts of the language. Smalltalk systems are different. They typically implement their own tools, and hence can lay claim to coding in a particular font in a way most other systems cant; they don't do fonts. > > > and yes... I was expecting a lot of whining (even if it was not me *alone* who took the decision), but I was expecting from people at least wait to see the fonts before start the bashing ;) > > Fuck off! Don't tell me I'm whining. OK, this discussion is the usual ad hominem piece of crap. Good bye. Again, I was not trying to insult anyone. I do found value in your arguments (and any others, no matter agreement or disagreement), and I was not trying to become nor personal not passionate and definitively not aggressive. I apologies, trying to make a fun comment I made a non-cool one. > > > > > >> On Oct 15, 2013, at 3:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >>> Excellent arguments ! > >>> I am with you 100% > >>> > >>> On 15 Oct 2013, at 15:21, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> Since the days when editors was able to allow me using any fonts, i was always switching to variable-spaced font > >>>> for code pane. And i am not speaking about smalltalk or pharo here, it was C and Pascal those days :) > >>>> > >>>> guess, what i would prefer in pharo? :) > >>>> > >>>> The bad things about getting used to monospaced fonts is that you format code and it looks perfect, > >>>> but then you print it or copy/paste it somewhere else where it uses other font, and all your beautiful formatting are gone. > >>>> Needless to say, that printing press was invented way before first computer or digital printer, and all we know about fonts came > >>>> to us from the printing world.. and i think i would be right saying that before first digital printers there was not such thing as monospaced > >>>> fonts, because it is not economically efficient: you don't want to waste space on front page of your newspaper by aligning glyphs to some virtual grid. > >>>> More than that, it works well only if you using same font size and no bold/underline variants whatever.. as soon as you use variants or different font size, > >>>> all the benefits of 'formatting' using monospaced font is gone. > >>>> That means, if we employ monospaced font for code, we will be forced to not use bold/italic variants, or different font size (for instance, > >>>> i would be like to play with code highlight scheme, where comments using different font size, or where method name uses bigger font size etc). > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Igor Stasenko. > >>> > >>> > >> > >> > > > > > > > > > > -- > best, > Eliot

Oct. 15, 2013

Re: [Pharo-dev] [Pharo-users] Please contributors fill up thisform...

by Gary Chambers

For update... PharoContributor new name: 'Gary Chambers'; email: 'gazzaguru2(a)btinternet.com'; website: 'http://www.flickr.com/people/12018791@N06/'; description: 'Software Engineer at Pinesoft. Smalltalk developer for over 24 years now! Creator of Polymorph UI framework.'; yourself. Regards, Gary ----- Original Message ----- From: Norbert Hartl To: Any question about pharo is welcome Cc: Pharo Development List Sent: Tuesday, October 15, 2013 11:32 AM Subject: Re: [Pharo-dev] [Pharo-users] Please contributors fill up thisform... PharoContributor new name: 'Norbert Hartl'; email: 'norbert(a)hartl.name'; website: 'http://norbert.hartl.name'; description: 'Software engineer at 2denker GmbH, cologne, germany.'; yourself. Am 09.10.2013 um 13:34 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: Hi guys I would like to get contributors.pharo.org a bit more representative of Pharo. We should have Previous contributors and enhance the current list. Can you please reply to this mail PharoContributor new name: 'Esteban Lorenzano'; id: 'estebanlm'; email: 'estebanlm(a)gmail.com'; website: 'http://smallworks.eu'; description: 'Pharo core team. Contributor of several projects, including Kernel, DBXTalk, Voyage, Mars, etc. Also I work on the VM.'; image: 'http://www.gravatar.com/avatar/193af464509ae8fbcc04abad70b72fc0?s=120'; yourself Stef

Oct. 15, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30487 Home: https://github.com/pharo-project/pharo-core

Oct. 15, 2013

[pharo-project/pharo-core] 2eb70a: 30487

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 2eb70a411d6e854020dac2f2b4a6885770282847 https://github.com/pharo-project/pharo-core/commit/2eb70a411d6e854020dac2f2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-15 (Tue, 15 Oct 2013) Changed paths: R AST-Interpreter-Core.package/AIContextInspector.class/README.md R AST-Interpreter-Core.package/AIContextInspector.class/definition.st R AST-Interpreter-Core.package/AIContextInspector.class/instance/accessing/contextStack.st R AST-Interpreter-Core.package/AIContextInspector.class/instance/accessing/fieldList.st R AST-Interpreter-Core.package/AIContextInspector.class/instance/selecting/printSelection.st R AST-Interpreter-Core.package/AIContextInspector.class/instance/selecting/selection.st R AST-Interpreter-Core.package/AIContextInspector.class/instance/selecting/selectionPrintString.st R NECompletion.package/extension/Inspector/instance/guessTypeForName_.st R NECompletion.package/extension/Inspector/instance/isCodeCompletionAllowed.st R Polymorph-TaskbarIcons.package/extension/Inspector/class/taskbarIcon.st R Polymorph-TaskbarIcons.package/extension/Inspector/instance/taskbarIcon.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script142.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30487.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Shout-Parsing.package/extension/Inspector/instance/shoutParser_.st R Shout-Styling.package/extension/Inspector/instance/shoutAboutToStyle_.st R Tools-Inspector.package/BasicInspector.class/README.md R Tools-Inspector.package/BasicInspector.class/class/tools registry/registerToolsOn_.st R Tools-Inspector.package/BasicInspector.class/definition.st R Tools-Inspector.package/BasicInspector.class/instance/initialization/inspect_.st R Tools-Inspector.package/CompiledMethodInspector.class/README.md R Tools-Inspector.package/CompiledMethodInspector.class/definition.st R Tools-Inspector.package/CompiledMethodInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/CompiledMethodInspector.class/instance/selecting/contentsIsString.st R Tools-Inspector.package/CompiledMethodInspector.class/instance/selecting/selection.st R Tools-Inspector.package/CompiledMethodInspector.class/instance/selecting/selectionUnmodifiable.st R Tools-Inspector.package/ContextInspector.class/README.md R Tools-Inspector.package/ContextInspector.class/definition.st R Tools-Inspector.package/ContextInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/ContextInspector.class/instance/accessing/selection.st R Tools-Inspector.package/DictionaryInspector.class/README.md R Tools-Inspector.package/DictionaryInspector.class/class/menu/menuDictionaryFieldList_.st R Tools-Inspector.package/DictionaryInspector.class/definition.st R Tools-Inspector.package/DictionaryInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/DictionaryInspector.class/instance/initialization/initialize.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/addEntry.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/copyName.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/fieldListMenu_.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/removeSelection.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/renameEntry.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/selectionReferences.st R Tools-Inspector.package/DictionaryInspector.class/instance/menu/sendersOfSelectedKey.st R Tools-Inspector.package/DictionaryInspector.class/instance/selecting/addEntry_.st R Tools-Inspector.package/DictionaryInspector.class/instance/selecting/calculateKeyArray.st R Tools-Inspector.package/DictionaryInspector.class/instance/selecting/contentsIsString.st R Tools-Inspector.package/DictionaryInspector.class/instance/selecting/refreshView.st R Tools-Inspector.package/DictionaryInspector.class/instance/selecting/replaceSelectionValue_.st R Tools-Inspector.package/DictionaryInspector.class/instance/selecting/selection.st R Tools-Inspector.package/FloatInspector.class/README.md R Tools-Inspector.package/FloatInspector.class/definition.st R Tools-Inspector.package/FloatInspector.class/instance/accessing/elements.st R Tools-Inspector.package/FloatInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/FloatInspector.class/instance/selecting/numberOfFixedFields.st R Tools-Inspector.package/FloatInspector.class/instance/selecting/replaceSelectionValue_.st R Tools-Inspector.package/FloatInspector.class/instance/selecting/selection.st R Tools-Inspector.package/Inspector.class/README.md R Tools-Inspector.package/Inspector.class/class/instance creation/horizontalDividerProportion.st R Tools-Inspector.package/Inspector.class/class/instance creation/inspect_.st R Tools-Inspector.package/Inspector.class/class/instance creation/openAsMorphOn_withEvalPane_withLabel_valueViewClass_.st R Tools-Inspector.package/Inspector.class/class/instance creation/openAsMorphOn_withLabel_.st R Tools-Inspector.package/Inspector.class/class/instance creation/openOn_.st R Tools-Inspector.package/Inspector.class/class/instance creation/openOn_withEvalPane_.st R Tools-Inspector.package/Inspector.class/class/instance creation/openOn_withEvalPane_withLabel_.st R Tools-Inspector.package/Inspector.class/class/instance creation/verticalDividerProportion.st R Tools-Inspector.package/Inspector.class/class/menu/menuFieldList_.st R Tools-Inspector.package/Inspector.class/class/tools registry/registerToolsOn_.st R Tools-Inspector.package/Inspector.class/definition.st R Tools-Inspector.package/Inspector.class/instance/accessing/baseFieldList.st R Tools-Inspector.package/Inspector.class/instance/accessing/contents.st R Tools-Inspector.package/Inspector.class/instance/accessing/contentsSelection.st R Tools-Inspector.package/Inspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/Inspector.class/instance/accessing/i1.st R Tools-Inspector.package/Inspector.class/instance/accessing/i2.st R Tools-Inspector.package/Inspector.class/instance/accessing/initialExtent.st R Tools-Inspector.package/Inspector.class/instance/accessing/modelWakeUpIn_.st R Tools-Inspector.package/Inspector.class/instance/accessing/noteSelectionIndex_for_.st R Tools-Inspector.package/Inspector.class/instance/accessing/object.st R Tools-Inspector.package/Inspector.class/instance/accessing/object_.st R Tools-Inspector.package/Inspector.class/instance/accessing/selectedClass.st R Tools-Inspector.package/Inspector.class/instance/accessing/selectedClassOrMetaClass.st R Tools-Inspector.package/Inspector.class/instance/accessing/stepTimeIn_.st R Tools-Inspector.package/Inspector.class/instance/accessing/timeOfLastListUpdate.st R Tools-Inspector.package/Inspector.class/instance/accessing/trashSelector.st R Tools-Inspector.package/Inspector.class/instance/accessing/trash_.st R Tools-Inspector.package/Inspector.class/instance/accessing/update.st R Tools-Inspector.package/Inspector.class/instance/accessing/wantsSteps.st R Tools-Inspector.package/Inspector.class/instance/as yet unclassified/exploreStrongPointers.st R Tools-Inspector.package/Inspector.class/instance/code/doItReceiver.st R Tools-Inspector.package/Inspector.class/instance/initialization/initialize.st R Tools-Inspector.package/Inspector.class/instance/initialization/inspect_.st R Tools-Inspector.package/Inspector.class/instance/menu commands/browseClass.st R Tools-Inspector.package/Inspector.class/instance/menu commands/browseClassRefs.st R Tools-Inspector.package/Inspector.class/instance/menu commands/browseClassVariables.st R Tools-Inspector.package/Inspector.class/instance/menu commands/browseInstVarDefs.st R Tools-Inspector.package/Inspector.class/instance/menu commands/browseInstVarRefs.st R Tools-Inspector.package/Inspector.class/instance/menu commands/browseMethodFull.st R Tools-Inspector.package/Inspector.class/instance/menu commands/classHierarchy.st R Tools-Inspector.package/Inspector.class/instance/menu commands/classOfSelection.st R Tools-Inspector.package/Inspector.class/instance/menu commands/classVarRefs.st R Tools-Inspector.package/Inspector.class/instance/menu commands/codePaneMenu_shifted_.st R Tools-Inspector.package/Inspector.class/instance/menu commands/copyName.st R Tools-Inspector.package/Inspector.class/instance/menu commands/defsOfSelection.st R Tools-Inspector.package/Inspector.class/instance/menu commands/doItContext.st R Tools-Inspector.package/Inspector.class/instance/menu commands/explorePointers.st R Tools-Inspector.package/Inspector.class/instance/menu commands/exploreSelection.st R Tools-Inspector.package/Inspector.class/instance/menu commands/fieldListMenu_.st R Tools-Inspector.package/Inspector.class/instance/menu commands/inspectBasic.st R Tools-Inspector.package/Inspector.class/instance/menu commands/inspectElement.st R Tools-Inspector.package/Inspector.class/instance/menu commands/inspectSelection.st R Tools-Inspector.package/Inspector.class/instance/menu commands/inspectorKey_from_.st R Tools-Inspector.package/Inspector.class/instance/menu commands/referencesToSelection.st R Tools-Inspector.package/Inspector.class/instance/private/numberOfFixedFields.st R Tools-Inspector.package/Inspector.class/instance/private/printStringErrorText.st R Tools-Inspector.package/Inspector.class/instance/selecting/accept_.st R Tools-Inspector.package/Inspector.class/instance/selecting/contentsIsString.st R Tools-Inspector.package/Inspector.class/instance/selecting/replaceSelectionValue_.st R Tools-Inspector.package/Inspector.class/instance/selecting/selectedSlotName.st R Tools-Inspector.package/Inspector.class/instance/selecting/selection.st R Tools-Inspector.package/Inspector.class/instance/selecting/selectionIndex.st R Tools-Inspector.package/Inspector.class/instance/selecting/selectionPrintString.st R Tools-Inspector.package/Inspector.class/instance/selecting/selectionUnmodifiable.st R Tools-Inspector.package/Inspector.class/instance/selecting/toggleIndex_.st R Tools-Inspector.package/Inspector.class/instance/stepping/stepAt_in_.st R Tools-Inspector.package/IntegerInspector.class/README.md R Tools-Inspector.package/IntegerInspector.class/definition.st R Tools-Inspector.package/IntegerInspector.class/instance/accessing/binary.st R Tools-Inspector.package/IntegerInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/IntegerInspector.class/instance/accessing/hex.st R Tools-Inspector.package/IntegerInspector.class/instance/accessing/octal.st R Tools-Inspector.package/IntegerInspector.class/instance/accessing/printStringBase_.st R Tools-Inspector.package/IntegerInspector.class/instance/accessing/representations.st R Tools-Inspector.package/IntegerInspector.class/instance/selecting/replaceSelectionValue_.st R Tools-Inspector.package/IntegerInspector.class/instance/selecting/selection.st R Tools-Inspector.package/OrderedCollectionInspector.class/README.md R Tools-Inspector.package/OrderedCollectionInspector.class/definition.st R Tools-Inspector.package/OrderedCollectionInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/OrderedCollectionInspector.class/instance/selecting/replaceSelectionValue_.st R Tools-Inspector.package/OrderedCollectionInspector.class/instance/selecting/selectedObjectIndex.st R Tools-Inspector.package/OrderedCollectionInspector.class/instance/selecting/selection.st R Tools-Inspector.package/SetInspector.class/README.md R Tools-Inspector.package/SetInspector.class/class/menu/menuDictionaryFieldList_.st R Tools-Inspector.package/SetInspector.class/definition.st R Tools-Inspector.package/SetInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/SetInspector.class/instance/menu commands/copyName.st R Tools-Inspector.package/SetInspector.class/instance/menu/fieldListMenu_.st R Tools-Inspector.package/SetInspector.class/instance/menu/removeSelection.st R Tools-Inspector.package/SetInspector.class/instance/selecting/arrayIndexForSelection.st R Tools-Inspector.package/SetInspector.class/instance/selecting/replaceSelectionValue_.st R Tools-Inspector.package/SetInspector.class/instance/selecting/selection.st R Tools-Inspector.package/WeakSetInspector.class/README.md R Tools-Inspector.package/WeakSetInspector.class/definition.st R Tools-Inspector.package/WeakSetInspector.class/instance/accessing/fieldList.st R Tools-Inspector.package/WeakSetInspector.class/instance/initialization/initialize.st R Tools-Inspector.package/extension/TBehavior/instance/inspectAllInstances.st R Tools-Inspector.package/extension/TBehavior/instance/inspectSubInstances.st A Tools.package/extension/TBehavior/instance/inspectAllInstances.st A Tools.package/extension/TBehavior/instance/inspectSubInstances.st Log Message: ----------- 30487 11015 Remove old Inspector https://pharo.fogbugz.com/f/cases/11015 http://files.pharo.org/image/30/30487.zip

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Esteban Lorenzano

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Subject: Re: [Pharo-dev] default monospaced code font > Date: October 15, 2013 5:37:33 PM GMT+02:00 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > > > On Tue, Oct 15, 2013 at 7:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Oct 15, 2013, at 3:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > On Oct 15, 2013, at 6:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> > >> On Oct 15, 2013, at 1:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >>> > >>> On 15 Oct 2013, at 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>> > >>>> well... fonts and UX in general are two different (yet related) issues. > >>>> > >>>> UX is a huge an complicated task, and has to be taken very seriously if we want to succeed. To allow the appropriate/productive/happy flows in an environment requires a lot of effort and to put all the pieces together. > >>>> Yes, I know, that sounds so general that is like not saying anything :) > >>>> Here is the concrete: Put all the UX pieces together requires a lot of effort usually not taken into account. That's how the UX evolved more or less the same way as morphic: a patch over a patch without much thinking about the issue, just takign what is there and parching/extending as needed. As morphic, the current UX in pharo is broken: there is no coherence between tools and sometimes even inside the same tool (for example nautilus has different behavior inside the code panel than in the list panels on top). > >>>> This is not the fault of any tool, just a consequence of how evolution was managed until now. > >>>> So, we wanted a better UX for Pharo3 that included: a new Theme, new Icon set, and new tools that worked well together. But task demonstrated to be a hard to beat beast, and we just moved forward in small areas (there is for example a new centralized menu coming along with a new spotlight). > >>>> And there is a prototype of a new theme and also some icons that where thought specially and that will fit nicely. But they will not be ready this year and after thinking a while (and getting feedback of people in community), we decided, for Pharo3: > >>>> > >>>> - adopt the glamour theme. This is a step forward our current one because glamour guys (specially Doru) continued working on it to have a really clean and simple theme. > >>>> - adopt the EclipsePack theme because is an iconset specially thought for programming that plays very well together. No matter if you do not like Eclipse (even if I think you are missing the relevance of Eclipse and a lot of good ideas that we could take from them), is about creating a unified vision. The old icon set (famfam) was not intended for programming environment and also there were a lot of different icons incorporated anarchically. > >>>> - adopt a monospaced font for coding (right now Source Code Pro) and a non-monospaced for the rest (right now Open Sans). > >>> > >>> I agree with everything, except the monospaced font. > >>> When, where, how was this decided ? I didn't see any discussion about this. > >>> I would be very surprised if you, or anyone else of the key developers, used that font. > >> > >> mmm... there was a "subjacent" discussion for months, but I agree that we should use more the list. > >> In any case, this is still an open discussion. > >> > >>> Anyone else having an opinion about the mono spaced font ? > >> > >>> > >>> It is not by erasing all differences with other systems that we will gain traction ! > >> > >> is not about erasing differences, is about not been different when been different does not follows a meaning. > >> I have my own experience to support my pov here: in my years teaching with pharo, I always had "lateral problems" with things that were not relevant... I would like to erase that, yes. To keep pharo been unique in the things that really matters. > > > > and Smalltalk is fundamentally different in its aesthetics and philosophy. Smalltalk was designed to be comprehensible by young people, not programmers. Just one example is the number base. Prefixing by 16r is more general, more powerful and more comprehensible than 0x, but is unfamiliar to most programmers. Throw that away and you end up with JavaScript or Ruby. > > I don't think is a fair comparison. > If that would be the case, we should still use a black and white theme with scrollbars in left and those horrible and pixelated fonts (no idea if there is a name for them). > > Nonsense. When that black and white theme was invented it was ground-breaking (the first scroll bars, the first pop-up menu, etc). But that doesn't mean one can't improve on things. While I liked the simple text selection cut/redo scheme, the Windows separation of cut/copy/paste from undo/redo is much better and I depend on that now. Pop-out scroll bars are a great idea for conserving screen real estate it is flickery and annoyingly difficult to aim at when not in the current pane, etc. When that black-and-whitew look was invented it was impossible even to conceive of a high-resolution colour display because memory was so expensive. There's nothing in the aesthetics or philosophy that pushes against evolution, or taking advantage of technological innovation. > > However, there /are/ ways in which Squeak/Pharo has regressed. In particular the lack of menu memory is IMO a right-royal PITA. (menu memory is popping up a menu such that the last item selected is under the cursor, and hence selected. now many menus are created when a mouse button is clicked, there is no menu object to remember the previous selection. this scheme makes it very nice to group menu selections in groups, since e.g. a repeated sequence of cut followed by paste is a simple sequence of gestures moving the cursor one menu selection up or down to get from cut to paste and back to paste again). > > > Progress is possible, > > Indeed it is. And moving from proportional to mono-spaced fonts is not progress, it is regress. > > perfection was not achieved in 81 or in 95. > > I didn't say it was. I said that systems designed with a coherent aesthetics and philosophy are more coherent, powerful and comprehensible than those which are not. yes, they are, I agree with that, and that's what we are trying to achieve... advancing one small step at a time, because we cannot doit all together, sadly. What I do not see is how proportional fonts fits more with a pharo coherence (which in my pov does not exists today) than a monospaced one. > > And I think erasing senseless barriers are closer to the spirit of the original smalltalk than stay immobile. > > Consider the number format. Is that a "senseless barrier" to comprehensibility that should be replaced by 0x? There are many ways one could approach the issues of formatting proportionally-spaced code. Eliminating it, when its readability and elegance is so much better than mono-spaced fonts, isn't removing a senseless barrier. More like tripping over a low hurdle. > > Said so... the day I ask for a semantic or even syntactic change is the day you can all bash me like the traitor I will become (but I would like to have a literal format...) ;) > > Stick to the argument, please. If this discussion devolves into the ad hominem then it'll achieve nothing. I was doing a joke, I'm sorry if it was not interpreted like that. But the think is I do not think the number example applies, because changing a font is not the same as changing syntax. I would disagree with changing syntax because I find smalltalk beauty and coherent, which is something that I do not see in the rest of the system. I think we agree in the objective of bring coherence to Pharo, probably not in the ways of doing it :) > > > What most other dynamic oo languages lack is an overall aesthetic and design philosophy. Just read the intro to the blue book to remind yourself of that philosophy and consider how deep and coherent it's effects on the system design are. All those other systems just want to be liked and are afraid to be different and are just a mess. If you want to make pharo blend in go ahead, but you'll end up with gruel, and insecure gruel at that. > > > > Monks paced fonts. Bah, humbug. > > > > Eliot (phone) > >> > >>> > >>> BTW: I don't see the any monospaced font in 30484, luckily ;-) > >>> > >>>> The objective is to offer a L&F that where visual elements plays well together. > >>>> And there is another more important (IMHO) objective: to offer newcomers an environment easier to approach. Pharo (and all Smalltalk-inspired environments) is already very alien for newcomers. We get a lot of power in exchange of that alienish stuff, but very often the curve of learning or acceptance is too high and people that could step closer to us are pushed away. So, my idea is to keep been as alien as possible in the things that make us Pharo and be the less alien possible in the rest: A nice L&F that can be feel as "some kind" familiar, is part of it. > >>>> > >>>> Said so... well you still can switch back to the old and ugly (IMO) L&F executing some lines of code in your workspace. > >>>> > >>>> Same to fonts: monospaced fonts is the worldwide accepted way of present source code. Why should we stay different? > >>>> > >>>> In any case, please give it a chance before drop it (once I can actually see why the fonts are not really applied) and we'll see how it works. > >>>> > >>>> Esteban > >>>> > >>>> > >>>> On Oct 15, 2013, at 12:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>> > >>>>> > >>>>> On 15 Oct 2013, at 08:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >>>>> > >>>>>> the issue that sets the new Pharo 3.0 look&feel uses a monospaced font > >>>>>> for the code. It is only a coincidence that it is not set this way in > >>>>>> the prebuild Pharo image. > >> > >> not a coincidence, a bug that arise when I tried to change it :) > >> > >>>>>> > >>>>>> I have big doubts if this is the way to go. I think that proportional > >>>>>> fonts are more natural for Smalltalk and without them the code is > >>>>>> harder to read and not so beauty. I think that something like elastic > >>>>>> tabstops would be much better solution. > >>>>>> http://tibleiz.net/code-browser/elastic-tabstops.html > >> > >> Well... we can still iterate over the idea before release, but we do the best we can with the tools we have in the moment :) > >> For me, is frankly uncomfortable to use proportional fonts when coding... is so annoying that I even use monospaced for lists, etc... but well, I accept the "current legislation": monospaced for code, proportional for the rest. > >> > >>>>> > >>>>> Yeah, I can't imagine many Smalltalkers liking a mono-spaced font, I personally hate it. > >> > >> Oh well, I'm a pharoer, and I love them :) > >> > >> > >>>>> > >>>>>> On the other way, it is only my personal opinion and if you think that > >>>>>> the Eclipse-like look will attract more new users... > >>>>> > >>>>> I don't like Eclipse ;-) But like Marcus says, it is just a different icon set. We want win any points on originality or personality though, which is a missed opportunity. > >> > >> > > > > > > > > -- > best, > Eliot

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Pavel Krivanek

2013/10/15 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On Oct 15, 2013, at 4:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 15 Oct 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> except that it is not accurate :) >>> >>> - with a monospace you can have bolds and italic without problems (it is a decent one)... and you also can play with sizes (for example, for comments) >>> - when you copy&paste you will lose part of your formatting no matter if you have a fixed font or a proportional one (is not true that you lose all of them... in fact I usually do not lose any) >> >> Sorry, but there are no sensible arguments in favour of a monospaced font. It is just not needed (in Smalltalk). Another way to look at it is: 99.99 % of the world use proportional fonts. >> >> BTW, I think whoever made this 'decision' knew it would be _very_ hard to get this passed ;-) >> >> Maybe we should switch to C/Java/Javascript syntax so that we do not scare newcomers ? Sorry, I could not resist. > not taken. > and non sense. > idea is to welcome newcomers, not to became another language. > Now... if font is *part* of the language, we could be talking about the same. But since it is not, then we are comparing apples with tomatoes. > > I can say that no, 99% of the world do not use proportional fonts... every other programing environment uses monospaced fonts. > yeah, I know "we are different"... but we still code. Ah, no, sorry... we "manipulate objects", but that looks really close to coding for me. > > and yes... I was expecting a lot of whining (even if it was not me *alone* who took the decision), but I was expecting from people at least wait to see the fonts before start the bashing ;) 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 >> >>> On Oct 15, 2013, at 3:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> Excellent arguments ! >>>> I am with you 100% >>>> >>>> On 15 Oct 2013, at 15:21, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> Since the days when editors was able to allow me using any fonts, i was always switching to variable-spaced font >>>>> for code pane. And i am not speaking about smalltalk or pharo here, it was C and Pascal those days :) >>>>> >>>>> guess, what i would prefer in pharo? :) >>>>> >>>>> The bad things about getting used to monospaced fonts is that you format code and it looks perfect, >>>>> but then you print it or copy/paste it somewhere else where it uses other font, and all your beautiful formatting are gone. >>>>> Needless to say, that printing press was invented way before first computer or digital printer, and all we know about fonts came >>>>> to us from the printing world.. and i think i would be right saying that before first digital printers there was not such thing as monospaced >>>>> fonts, because it is not economically efficient: you don't want to waste space on front page of your newspaper by aligning glyphs to some virtual grid. >>>>> More than that, it works well only if you using same font size and no bold/underline variants whatever.. as soon as you use variants or different font size, >>>>> all the benefits of 'formatting' using monospaced font is gone. >>>>> That means, if we employ monospaced font for code, we will be forced to not use bold/italic variants, or different font size (for instance, >>>>> i would be like to play with code highlight scheme, where comments using different font size, or where method name uses bigger font size etc). >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>> >>>> >>> >>> >> >> > >

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Eliot Miranda

On Tue, Oct 15, 2013 at 8:29 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am in favor of using monospaced fonts for the code and sans serif fonts > for the rest of the things. I pushed the Source Sans + Source Code fonts > for the Moose image since half a year, and actually people like the look of > them. I am a bit surprised to see such virulent reactions :). > again, ad hominem. > > @Sven: the mail discussions that led to the fonts choice had you in CC the > whole time :). > > Cheers, > Doru > > > > On Tue, Oct 15, 2013 at 5:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> >> On 15 Oct 2013, at 17:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> > >> > On Oct 15, 2013, at 4:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > >> >> >> >> On 15 Oct 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> >> >>> except that it is not accurate :) >> >>> >> >>> - with a monospace you can have bolds and italic without problems (it >> is a decent one)... and you also can play with sizes (for example, for >> comments) >> >>> - when you copy&paste you will lose part of your formatting no matter >> if you have a fixed font or a proportional one (is not true that you lose >> all of them... in fact I usually do not lose any) >> >> >> >> Sorry, but there are no sensible arguments in favour of a monospaced >> font. It is just not needed (in Smalltalk). Another way to look at it is: >> 99.99 % of the world use proportional fonts. >> >> >> >> BTW, I think whoever made this 'decision' knew it would be _very_ hard >> to get this passed ;-) >> >> >> >> Maybe we should switch to C/Java/Javascript syntax so that we do not >> scare newcomers ? Sorry, I could not resist. >> > not taken. >> > and non sense. >> > idea is to welcome newcomers, not to became another language. >> > Now... if font is *part* of the language, we could be talking about the >> same. But since it is not, then we are comparing apples with tomatoes. >> > >> > I can say that no, 99% of the world do not use proportional fonts... >> every other programing environment uses monospaced fonts. >> > yeah, I know "we are different"... but we still code. Ah, no, sorry... >> we "manipulate objects", but that looks really close to coding for me. >> > >> > and yes... I was expecting a lot of whining (even if it was not me >> *alone* who took the decision), but I was expecting from people at least >> wait to see the fonts before start the bashing ;) >> >> Well, it is not 'bashing', I just totally do not agree. >> And I would like to know who else is in favour, how the decision was made. >> But I'll wait a bit for other comments. >> >> >>> On Oct 15, 2013, at 3:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> >> >>>> Excellent arguments ! >> >>>> I am with you 100% >> >>>> >> >>>> On 15 Oct 2013, at 15:21, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>>> >> >>>>> Since the days when editors was able to allow me using any fonts, i >> was always switching to variable-spaced font >> >>>>> for code pane. And i am not speaking about smalltalk or pharo here, >> it was C and Pascal those days :) >> >>>>> >> >>>>> guess, what i would prefer in pharo? :) >> >>>>> >> >>>>> The bad things about getting used to monospaced fonts is that you >> format code and it looks perfect, >> >>>>> but then you print it or copy/paste it somewhere else where it uses >> other font, and all your beautiful formatting are gone. >> >>>>> Needless to say, that printing press was invented way before first >> computer or digital printer, and all we know about fonts came >> >>>>> to us from the printing world.. and i think i would be right saying >> that before first digital printers there was not such thing as monospaced >> >>>>> fonts, because it is not economically efficient: you don't want to >> waste space on front page of your newspaper by aligning glyphs to some >> virtual grid. >> >>>>> More than that, it works well only if you using same font size and >> no bold/underline variants whatever.. as soon as you use variants or >> different font size, >> >>>>> all the benefits of 'formatting' using monospaced font is gone. >> >>>>> That means, if we employ monospaced font for code, we will be >> forced to not use bold/italic variants, or different font size (for >> instance, >> >>>>> i would be like to play with code highlight scheme, where comments >> using different font size, or where method name uses bigger font size etc). >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Best regards, >> >>>>> Igor Stasenko. >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- best, Eliot

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Eliot Miranda

On Tue, Oct 15, 2013 at 8:05 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On Oct 15, 2013, at 4:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 15 Oct 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> except that it is not accurate :) > >> > >> - with a monospace you can have bolds and italic without problems (it > is a decent one)... and you also can play with sizes (for example, for > comments) > >> - when you copy&paste you will lose part of your formatting no matter > if you have a fixed font or a proportional one (is not true that you lose > all of them... in fact I usually do not lose any) > > > > Sorry, but there are no sensible arguments in favour of a monospaced > font. It is just not needed (in Smalltalk). Another way to look at it is: > 99.99 % of the world use proportional fonts. > > > > BTW, I think whoever made this 'decision' knew it would be _very_ hard > to get this passed ;-) > > > > Maybe we should switch to C/Java/Javascript syntax so that we do not > scare newcomers ? Sorry, I could not resist. > not taken. > and non sense. > idea is to welcome newcomers, not to became another language. > Now... if font is *part* of the language, we could be talking about the > same. But since it is not, then we are comparing apples with tomatoes. > Smalltalk is much more than a language. It is also a class library, an incremental/interactive development environment, a set of tools, a number of graphics systems, a system for manipulating multiple media, and so on. Part of that is an aesthetic, especially when applied to the primary communications medium in the sytsem, text. So the apples with tomatoes "critique" is baloney. I can say that no, 99% of the world do not use proportional fonts... every > other programing environment uses monospaced fonts. > yeah, I know "we are different"... but we still code. Ah, no, sorry... we > "manipulate objects", but that looks really close to coding for me. > That's wrong. Few languages have been used to implement their own display system. Development "in" those languages is in fact, merely editing in whatever toolset the programmer chooses and not an integral part of the language at all. So most other languages neither use, nor don't use proportional or mono-spaced font. They are orthogonal to fonts. They are purely sequences of characters. Programmers impose formatting conventions to make texts that denote programs in those languages readable. But those languages are font-agnostic, and the conventions not integral parts of the language. Smalltalk systems are different. They typically implement their own tools, and hence can lay claim to coding in a particular font in a way most other systems cant; they don't do fonts. > > and yes... I was expecting a lot of whining (even if it was not me *alone* > who took the decision), but I was expecting from people at least wait to > see the fonts before start the bashing ;) > Fuck off! Don't tell me I'm whining. OK, this discussion is the usual ad hominem piece of crap. Good bye. > > > > > >> On Oct 15, 2013, at 3:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > >>> Excellent arguments ! > >>> I am with you 100% > >>> > >>> On 15 Oct 2013, at 15:21, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> Since the days when editors was able to allow me using any fonts, i > was always switching to variable-spaced font > >>>> for code pane. And i am not speaking about smalltalk or pharo here, > it was C and Pascal those days :) > >>>> > >>>> guess, what i would prefer in pharo? :) > >>>> > >>>> The bad things about getting used to monospaced fonts is that you > format code and it looks perfect, > >>>> but then you print it or copy/paste it somewhere else where it uses > other font, and all your beautiful formatting are gone. > >>>> Needless to say, that printing press was invented way before first > computer or digital printer, and all we know about fonts came > >>>> to us from the printing world.. and i think i would be right saying > that before first digital printers there was not such thing as monospaced > >>>> fonts, because it is not economically efficient: you don't want to > waste space on front page of your newspaper by aligning glyphs to some > virtual grid. > >>>> More than that, it works well only if you using same font size and no > bold/underline variants whatever.. as soon as you use variants or different > font size, > >>>> all the benefits of 'formatting' using monospaced font is gone. > >>>> That means, if we employ monospaced font for code, we will be forced > to not use bold/italic variants, or different font size (for instance, > >>>> i would be like to play with code highlight scheme, where comments > using different font size, or where method name uses bigger font size etc). > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Igor Stasenko. > >>> > >>> > >> > >> > > > > > > > -- best, Eliot

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Jimmie Houchin

On 10/15/2013 7:46 AM, Camillo Bruni wrote: > processing.org uses monospaced font, these are the art guys that have more sense graphics > than any one this mailinglist (BTW, how many of you have visited an art school?) > > Besides Smalltalk, I don't know any other language that would use proportial fonts. > > After that, anybody who really knows how to use Pharo can modify it. > The newcomer is the only one you target... Regarding Art School. No I haven't but my father-in-law did, one of my daughters is. Regardless, it doesn't matter. Not that either do fonts. Has anybody involved with vim or emacs been to art school? Two of the most used and fought over editors out there and they are as ugly as ... Yet their ugliness doesn't deter their advocates. Why? Because their advocates find value in what you can do with them. I am very much in the proportional camp. I spend my day typing, and writing in proportional fonts. One of the nice things about Smalltalk and any higher level language in theory is that it brings you somewhat closer to natural language. And in general most things we do in our natural languages is in a proportional font. And no, I don't believe we need a cognitive indicator which tells our brain that this is different. We are writing software not an article. Once upon a time all or almost everything done on a computer was in a monospace font. Regardless as to whether or not it was writing software or writing a novel. People who like monospace often prefer underscores and not camelCase. They also like 79 character line breaks and all other sorts of conventions created due to the environment they operate in. Other languages do not have fonts. They generally do not have editors. They are quite different from the Smalltalk experience. We should not impose their constraints into our environment. Users of those languages choose editors. Users of those editors choose fonts. The language itself imposes no such constraints or opinions outside of community convention. We do not operate in any of those environments. We should not feel compelled to impose any of those constraints. Yes, I agree. We should not be different for different sake. But, I find value in proportional fonts. Let me repeat that, I find value in the proportional font. Therefore I do not believe that using a proportional font is being different just to be different. I and most people who are not explicitly placing themselves in this context, coding, find them to be more readable. Are magazines, newspapers, books, websites mainly in monospace? Most of what we read is proportional for a reason. Yes, anybody can change their personal use of the system and choose monospace or proportional. There is great value in establishing a good community standard for the image. Not necessarily a standard that is catering to beginners current comforts. But one that is a good community default. A default which experienced Smalltalkers find productive. Then provide good learning tools to enable beginners to be on a path of increasing productivity. A beginner will often stay with what they start with for a very long time. So if our initial image is one that caters to beginners, then they may live their a very long time. And not to their betterment. I think we should be comfortable with and embrace who we (Smalltalkers/Pharo) are. Not seek to change unnecessarily to conform to a different standard which was established based upon different criteria and constraints which do not apply to us. I personally do not understand how so many people find Smalltalk to be uncomfortable or difficult. I am far from a pro Smalltalker. But I find nothing else to be as comfortable and productive as Smalltalk/Pharo. My only thoughts is that everybody thinks in different ways. People are drawn to languages work like they think. And for some people Smalltalk isn't it. I know I find many languages out there to be less than pleasant and ugly no matter what font they use. :) Just my opinions. Thanks. Jimmie

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Eliot Miranda

On Tue, Oct 15, 2013 at 7:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On Oct 15, 2013, at 3:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > > On Oct 15, 2013, at 6:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > >> > >> On Oct 15, 2013, at 1:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > >>> > >>> On 15 Oct 2013, at 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>> > >>>> well... fonts and UX in general are two different (yet related) > issues. > >>>> > >>>> UX is a huge an complicated task, and has to be taken very seriously > if we want to succeed. To allow the appropriate/productive/happy flows in > an environment requires a lot of effort and to put all the pieces together. > >>>> Yes, I know, that sounds so general that is like not saying anything > :) > >>>> Here is the concrete: Put all the UX pieces together requires a lot > of effort usually not taken into account. That's how the UX evolved more or > less the same way as morphic: a patch over a patch without much thinking > about the issue, just takign what is there and parching/extending as > needed. As morphic, the current UX in pharo is broken: there is no > coherence between tools and sometimes even inside the same tool (for > example nautilus has different behavior inside the code panel than in the > list panels on top). > >>>> This is not the fault of any tool, just a consequence of how > evolution was managed until now. > >>>> So, we wanted a better UX for Pharo3 that included: a new Theme, new > Icon set, and new tools that worked well together. But task demonstrated to > be a hard to beat beast, and we just moved forward in small areas (there is > for example a new centralized menu coming along with a new spotlight). > >>>> And there is a prototype of a new theme and also some icons that > where thought specially and that will fit nicely. But they will not be > ready this year and after thinking a while (and getting feedback of people > in community), we decided, for Pharo3: > >>>> > >>>> - adopt the glamour theme. This is a step forward our current one > because glamour guys (specially Doru) continued working on it to have a > really clean and simple theme. > >>>> - adopt the EclipsePack theme because is an iconset specially thought > for programming that plays very well together. No matter if you do not like > Eclipse (even if I think you are missing the relevance of Eclipse and a lot > of good ideas that we could take from them), is about creating a unified > vision. The old icon set (famfam) was not intended for programming > environment and also there were a lot of different icons incorporated > anarchically. > >>>> - adopt a monospaced font for coding (right now Source Code Pro) and > a non-monospaced for the rest (right now Open Sans). > >>> > >>> I agree with everything, except the monospaced font. > >>> When, where, how was this decided ? I didn't see any discussion about > this. > >>> I would be very surprised if you, or anyone else of the key > developers, used that font. > >> > >> mmm... there was a "subjacent" discussion for months, but I agree that > we should use more the list. > >> In any case, this is still an open discussion. > >> > >>> Anyone else having an opinion about the mono spaced font ? > >> > >>> > >>> It is not by erasing all differences with other systems that we will > gain traction ! > >> > >> is not about erasing differences, is about not been different when been > different does not follows a meaning. > >> I have my own experience to support my pov here: in my years teaching > with pharo, I always had "lateral problems" with things that were not > relevant... I would like to erase that, yes. To keep pharo been unique in > the things that really matters. > > > > and Smalltalk is fundamentally different in its aesthetics and > philosophy. Smalltalk was designed to be comprehensible by young people, > not programmers. Just one example is the number base. Prefixing by 16r is > more general, more powerful and more comprehensible than 0x, but is > unfamiliar to most programmers. Throw that away and you end up with > JavaScript or Ruby. > > I don't think is a fair comparison. > If that would be the case, we should still use a black and white theme > with scrollbars in left and those horrible and pixelated fonts (no idea if > there is a name for them). > Nonsense. When that black and white theme was invented it was ground-breaking (the first scroll bars, the first pop-up menu, etc). But that doesn't mean one can't improve on things. While I liked the simple text selection cut/redo scheme, the Windows separation of cut/copy/paste from undo/redo is much better and I depend on that now. Pop-out scroll bars are a great idea for conserving screen real estate it is flickery and annoyingly difficult to aim at when not in the current pane, etc. When that black-and-whitew look was invented it was impossible even to conceive of a high-resolution colour display because memory was so expensive. There's nothing in the aesthetics or philosophy that pushes against evolution, or taking advantage of technological innovation. However, there /are/ ways in which Squeak/Pharo has regressed. In particular the lack of menu memory is IMO a right-royal PITA. (menu memory is popping up a menu such that the last item selected is under the cursor, and hence selected. now many menus are created when a mouse button is clicked, there is no menu object to remember the previous selection. this scheme makes it very nice to group menu selections in groups, since e.g. a repeated sequence of cut followed by paste is a simple sequence of gestures moving the cursor one menu selection up or down to get from cut to paste and back to paste again). > Progress is possible, Indeed it is. And moving from proportional to mono-spaced fonts is not progress, it is regress. > perfection was not achieved in 81 or in 95. > I didn't say it was. I said that systems designed with a coherent aesthetics and philosophy are more coherent, powerful and comprehensible than those which are not. And I think erasing senseless barriers are closer to the spirit of the > original smalltalk than stay immobile. > Consider the number format. Is that a "senseless barrier" to comprehensibility that should be replaced by 0x? There are many ways one could approach the issues of formatting proportionally-spaced code. Eliminating it, when its readability and elegance is so much better than mono-spaced fonts, isn't removing a senseless barrier. More like tripping over a low hurdle. > Said so... the day I ask for a semantic or even syntactic change is the > day you can all bash me like the traitor I will become (but I would like to > have a literal format...) ;) > Stick to the argument, please. If this discussion devolves into the ad hominem then it'll achieve nothing. > What most other dynamic oo languages lack is an overall aesthetic and > design philosophy. Just read the intro to the blue book to remind yourself > of that philosophy and consider how deep and coherent it's effects on the > system design are. All those other systems just want to be liked and are > afraid to be different and are just a mess. If you want to make pharo > blend in go ahead, but you'll end up with gruel, and insecure gruel at that. > > > > Monks paced fonts. Bah, humbug. > > > > Eliot (phone) > >> > >>> > >>> BTW: I don't see the any monospaced font in 30484, luckily ;-) > >>> > >>>> The objective is to offer a L&F that where visual elements plays well > together. > >>>> And there is another more important (IMHO) objective: to offer > newcomers an environment easier to approach. Pharo (and all > Smalltalk-inspired environments) is already very alien for newcomers. We > get a lot of power in exchange of that alienish stuff, but very often the > curve of learning or acceptance is too high and people that could step > closer to us are pushed away. So, my idea is to keep been as alien as > possible in the things that make us Pharo and be the less alien possible in > the rest: A nice L&F that can be feel as "some kind" familiar, is part of > it. > >>>> > >>>> Said so... well you still can switch back to the old and ugly (IMO) > L&F executing some lines of code in your workspace. > >>>> > >>>> Same to fonts: monospaced fonts is the worldwide accepted way of > present source code. Why should we stay different? > >>>> > >>>> In any case, please give it a chance before drop it (once I can > actually see why the fonts are not really applied) and we'll see how it > works. > >>>> > >>>> Esteban > >>>> > >>>> > >>>> On Oct 15, 2013, at 12:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> > >>>>> > >>>>> On 15 Oct 2013, at 08:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >>>>> > >>>>>> the issue that sets the new Pharo 3.0 look&feel uses a monospaced > font > >>>>>> for the code. It is only a coincidence that it is not set this way > in > >>>>>> the prebuild Pharo image. > >> > >> not a coincidence, a bug that arise when I tried to change it :) > >> > >>>>>> > >>>>>> I have big doubts if this is the way to go. I think that > proportional > >>>>>> fonts are more natural for Smalltalk and without them the code is > >>>>>> harder to read and not so beauty. I think that something like > elastic > >>>>>> tabstops would be much better solution. > >>>>>> http://tibleiz.net/code-browser/elastic-tabstops.html > >> > >> Well... we can still iterate over the idea before release, but we do > the best we can with the tools we have in the moment :) > >> For me, is frankly uncomfortable to use proportional fonts when > coding... is so annoying that I even use monospaced for lists, etc... but > well, I accept the "current legislation": monospaced for code, proportional > for the rest. > >> > >>>>> > >>>>> Yeah, I can't imagine many Smalltalkers liking a mono-spaced font, I > personally hate it. > >> > >> Oh well, I'm a pharoer, and I love them :) > >> > >> > >>>>> > >>>>>> On the other way, it is only my personal opinion and if you think > that > >>>>>> the Eclipse-like look will attract more new users... > >>>>> > >>>>> I don't like Eclipse ;-) But like Marcus says, it is just a > different icon set. We want win any points on originality or personality > though, which is a missed opportunity. > >> > >> > > > > > -- best, Eliot

Oct. 15, 2013