August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Dark Mode

by phil＠highoctane.be

White all over Smalltalks UIs are a reason why I do *not* use them. Dark Pharo: good. Properly themeable Pharo with a palette and logical color mappings: nirvana. I hope to contribute to that. I did some GToolkit dark theming but it was too late for 6.0 so maybe for 7. Try to code against a white background when you have floaters casting shadows on your retina. I sucks big time. I noticed that a lot of older folk suffer from this. I once had a guy who wasn't telling younger team members that he wasn't able to read their document due to too small fonts. We are talking C level executives here... These accessibility issues are going to become huge with people getting older and having cash to spend. >From what I can so see, hearing problems will be quite a thing with newer generations. Anyway, there is NegativeScreen on Windows to get whatever I want. http://arcanesanctum.net/negativescreen/ Phil On Aug 29, 2017 6:02 AM, "Markus Stumptner" <mst(a)cs.unisa.edu.au> wrote: > On 28/08/17 06:07, Dimitris Chloupis wrote: > > >> I completely agree - dark mode is great for content that you want to >> look cool, but no one consumes. :-) >> > > You assume wrong cause dark themes have been dominating GUIs for over 3 > decades now. > > Not really; bright on dark was only dominant in the days of the CRT > terminal when there were no "themes". (Even if you could do it as a > hardware switch, setting, say, a VT220 to black-on-white both looked > terrible as it was more an uneven gray, and tended to dim the tube more > quickly by burning in the background.) > > Instead, since full bitmap graphics happened, all screen interfaces back > to Xerox's prototype office systems, then Lisa/Macintosh, and then Windows > 2.1 have been using dark type on a white background for text work. Partly > this was because of the original office metaphor, but partly also because > it was shown that it was easier (meaning, less error prone) to read. > > Here's a study that showed that participants were 26% more accurate in > reading text that way (note that "contrast reversal" on displays in those > days meant dark characters on white background): > > Bauer, D., & Cavonius, C., R. (1980). Improving the legibility of visual > display units through contrast reversal. > In E. Grandjean, E. Vigliani (Eds.), Ergonomic Aspects of Visual Display > Terminals (pp. 137-142). > London: Taylor & Francis > > There were other studies in the 1980s that didn't report lower errors but > instead faster reading with black on white. Academically, the matter's > pretty much considered settled - black on white is better for most of the > population, and that's on screen, not on paper. (You can substitute any > degree of light or creamy for the white, that's really a variation of > screen quality.) > The engineering workstations of the late 80s and 90s (Sun etc) used black > and white as the application default as well, with white on black limited > to console/shell windows. This was partly for consistency with the old > style, partly for easy contrast with application windows in a multi-window > environment. > > Pharo was the rare exception of using a white theme. Light themes may be > popular but white are definitely not. The web is the last fort of bright > themes, but the web was and still is eons behind when it comes to matters > of UI. > > Most other Smalltalks are dark-on-light by default all the way back to > Smalltalk-80 out of Xerox PARC. None of this had anything to do with the > Web, which came after, but which obviously also profits from the same > increase in readability. Rather than behind, Smalltalk was ahead and the > rest of the world followed. > > The dark theme as default in Pharo I personally consider a step back. As > someone who's been busy for 25+ years defending use of Smalltalk for real > applications, a return to a primarily developer-cool presentation instead > of a user-oriented default is IMO not a plus for a language branch that was > billed as more industry-oriented (which IMO is not exactly the same as > developer-oriented). But I also understand the desire to attract > developers with the look that's currently fashionable. > > That said, I wonder if the recent preference for dark among developers > (not Pharo-specific, but many languages) has to do with the rise of > widespread code highlighting. I could see how colour highlighting shows up > better on a dark background than being glared over by a white one. > > Markus >

Aug. 29, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

80s was the time of home computer with 1985 the rise of Amiga which was light years ahead of theme support, it practically established GUIs, GPU, dedicated hardware components, gaming, computer graphics and of course 3d graphics, together with many other things. Plus a theme was super easy to make because all you had to do is change the colour of foreground and background. Smalltalk lost its chance by making a huge mistake investing on Apple instead of Home computers. BASIC on the other hand did not make that mistake and its creators made sure it was available on every home computer. You turned on the computer and immediately sent you to a BASIC interpreter that acted also as the OS. It was BASIC that established the dark theme popularity as it chose it as its dafault theme. Smalltalk faded, BASIC became insanely popular and still dominates mainly through Visual Basic and Visual Basic .NET. Smalltalk would have been amazing as game orientated , easy to learn , home computer OS replacement for BASIC. So I am not surprised that dark theme has been such a big discussion here even though its non existent discussion to any other software I have used. On Tue, Aug 29, 2017 at 7:03 AM Markus Stumptner <mst(a)cs.unisa.edu.au> wrote: > On 28/08/17 06:07, Dimitris Chloupis wrote: > > >> I completely agree - dark mode is great for content that you want to >> look cool, but no one consumes. :-) >> > > You assume wrong cause dark themes have been dominating GUIs for over 3 > decades now. > > Not really; bright on dark was only dominant in the days of the CRT > terminal when there were no "themes". (Even if you could do it as a > hardware switch, setting, say, a VT220 to black-on-white both looked > terrible as it was more an uneven gray, and tended to dim the tube more > quickly by burning in the background.) > > Instead, since full bitmap graphics happened, all screen interfaces back > to Xerox's prototype office systems, then Lisa/Macintosh, and then Windows > 2.1 have been using dark type on a white background for text work. Partly > this was because of the original office metaphor, but partly also because > it was shown that it was easier (meaning, less error prone) to read. > > Here's a study that showed that participants were 26% more accurate in > reading text that way (note that "contrast reversal" on displays in those > days meant dark characters on white background): > > Bauer, D., & Cavonius, C., R. (1980). Improving the legibility of visual > display units through contrast reversal. > In E. Grandjean, E. Vigliani (Eds.), Ergonomic Aspects of Visual Display > Terminals (pp. 137-142). > London: Taylor & Francis > > There were other studies in the 1980s that didn't report lower errors but > instead faster reading with black on white. Academically, the matter's > pretty much considered settled - black on white is better for most of the > population, and that's on screen, not on paper. (You can substitute any > degree of light or creamy for the white, that's really a variation of > screen quality.) > The engineering workstations of the late 80s and 90s (Sun etc) used black > and white as the application default as well, with white on black limited > to console/shell windows. This was partly for consistency with the old > style, partly for easy contrast with application windows in a multi-window > environment. > > > Pharo was the rare exception of using a white theme. Light themes may be > popular but white are definitely not. The web is the last fort of bright > themes, but the web was and still is eons behind when it comes to matters > of UI. > > Most other Smalltalks are dark-on-light by default all the way back to > Smalltalk-80 out of Xerox PARC. None of this had anything to do with the > Web, which came after, but which obviously also profits from the same > increase in readability. Rather than behind, Smalltalk was ahead and the > rest of the world followed. > > The dark theme as default in Pharo I personally consider a step back. As > someone who's been busy for 25+ years defending use of Smalltalk for real > applications, a return to a primarily developer-cool presentation instead > of a user-oriented default is IMO not a plus for a language branch that was > billed as more industry-oriented (which IMO is not exactly the same as > developer-oriented). But I also understand the desire to attract > developers with the look that's currently fashionable. > > That said, I wonder if the recent preference for dark among developers > (not Pharo-specific, but many languages) has to do with the rise of > widespread code highlighting. I could see how colour highlighting shows up > better on a dark background than being glared over by a white one. > > Markus >

Aug. 29, 2017

Re: [Pharo-users] CodeImporter. 256 literals limit

by ClÃ©ment Bera

Hi, If your tool works in Pharo 6, you can use the other bytecode set which supports up to 32k literals. To do so, go to: World Menu > Settings > Compiler > Encoder and pick SistaV1 instead of V3PlusClosures Try to load your code. The default Pharo 6 VM supports both bytecode sets. Alternatively you need to split your methods with many literals in multiple methods with less literals, which is usually quite tricky to do right. On Tue, Aug 29, 2017 at 4:52 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > I have written a tool (Pharo5) where user gives an input file to it, where > the content is a smalltalk code, a DSL. I used a subclass of CodeImporter > class to evaluate this input file. > > Recently my user used an input file where it hit the 256 literal limit > (total of unique string, number, method name, etc), down in > OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be > hard coded and related to byte code generator, not something I can simply > increase. I wasn't aware of this limitation. > > Before I overhaul my tool, I thought I should ask. Is there another > alternative to evaluate a smalltalk file/script? The file is small, 27k, > but the number of unique literals in it is > 256. Is it possible at all, > seeing that the limit is related to byte code generator. > > Thank you in advance > -- > Andreas Sunardi >

Aug. 29, 2017

Re: [Pharo-users] CodeImporter. 256 literals limit

by Marcus Denker

Hello, The new byte code set that we will use in the future does not hat this limitation. You can, but only in Pharo6 and later, the new byte code backend (it is called âSistaV1â). (this is a global preference to be enabled in the Settings). Marcus It is not yet used by default, but you can enable it. Either globally, or, > On 29 Aug 2017, at 04:52, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > I have written a tool (Pharo5) where user gives an input file to it, where the content is a smalltalk code, a DSL. I used a subclass of CodeImporter class to evaluate this input file. > > Recently my user used an input file where it hit the 256 literal limit (total of unique string, number, method name, etc), down in OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be hard coded and related to byte code generator, not something I can simply increase. I wasn't aware of this limitation. > > Before I overhaul my tool, I thought I should ask. Is there another alternative to evaluate a smalltalk file/script? The file is small, 27k, but the number of unique literals in it is > 256. Is it possible at all, seeing that the limit is related to byte code generator. > > Thank you in advance > -- > Andreas Sunardi

Aug. 29, 2017

Re: [Pharo-users] Dark Mode

by Markus Stumptner

On 28/08/17 06:07, Dimitris Chloupis wrote: > > > I completely agree - dark mode is great for content that you want to > look cool, but no one consumes. :-) > > > You assume wrong cause dark themes have been dominating GUIs for over > 3 decades now. Not really; bright on dark was only dominant in the days of the CRT terminal when there were no "themes". (Even if you could do it as a hardware switch, setting, say, a VT220 to black-on-white both looked terrible as it was more an uneven gray, and tended to dim the tube more quickly by burning in the background.) Instead, since full bitmap graphics happened, all screen interfaces back to Xerox's prototype office systems, then Lisa/Macintosh, and then Windows 2.1 have been using dark type on a white background for text work. Partly this was because of the original office metaphor, but partly also because it was shown that it was easier (meaning, less error prone) to read. Here's a study that showed that participants were 26% more accurate in reading text that way (note that "contrast reversal" on displays in those days meant dark characters on white background): Bauer, D., & Cavonius, C., R. (1980). Improving the legibility of visual display units through contrast reversal. In E. Grandjean, E. Vigliani (Eds.), Ergonomic Aspects of Visual Display Terminals (pp. 137-142). London: Taylor & Francis There were other studies in the 1980s that didn't report lower errors but instead faster reading with black on white. Academically, the matter's pretty much considered settled - black on white is better for most of the population, and that's on screen, not on paper. (You can substitute any degree of light or creamy for the white, that's really a variation of screen quality.) The engineering workstations of the late 80s and 90s (Sun etc) used black and white as the application default as well, with white on black limited to console/shell windows. This was partly for consistency with the old style, partly for easy contrast with application windows in a multi-window environment. > Pharo was the rare exception of using a white theme. Light themes may > be popular but white are definitely not. The web is the last fort of > bright themes, but the web was and still is eons behind when it comes > to matters of UI. Most other Smalltalks are dark-on-light by default all the way back to Smalltalk-80 out of Xerox PARC. None of this had anything to do with the Web, which came after, but which obviously also profits from the same increase in readability. Rather than behind, Smalltalk was ahead and the rest of the world followed. The dark theme as default in Pharo I personally consider a step back. As someone who's been busy for 25+ years defending use of Smalltalk for real applications, a return to a primarily developer-cool presentation instead of a user-oriented default is IMO not a plus for a language branch that was billed as more industry-oriented (which IMO is not exactly the same as developer-oriented). But I also understand the desire to attract developers with the look that's currently fashionable. That said, I wonder if the recent preference for dark among developers (not Pharo-specific, but many languages) has to do with the rise of widespread code highlighting. I could see how colour highlighting shows up better on a dark background than being glared over by a white one. Markus

Aug. 29, 2017

CodeImporter. 256 literals limit

by Andreas Sunardi

I have written a tool (Pharo5) where user gives an input file to it, where the content is a smalltalk code, a DSL. I used a subclass of CodeImporter class to evaluate this input file. Recently my user used an input file where it hit the 256 literal limit (total of unique string, number, method name, etc), down in OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be hard coded and related to byte code generator, not something I can simply increase. I wasn't aware of this limitation. Before I overhaul my tool, I thought I should ask. Is there another alternative to evaluate a smalltalk file/script? The file is small, 27k, but the number of unique literals in it is > 256. Is it possible at all, seeing that the limit is related to byte code generator. Thank you in advance -- Andreas Sunardi

Aug. 29, 2017

Re: [Pharo-users] Code mystery

by Dimitris Chloupis

You are not going crazy that's an ugly method. Probably the author intended to use dir and the forgot about it and instead hard coded the dir path inside a class method. A mistake that can happen to anyone. The method will have to be updated anyway because name is to be removed, so it won't work. As always too much code too few people. If you think that's bad embrace yourself if you try to read Morphic code. Huge suffering for me when I tried to learn how the task bar works and apparently using it wrong it freezes the image. Tons of Pharo code needs a clean but needs also a lot more people. On Tue, 29 Aug 2017 at 01:52, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Hello All > > > > Following the discussion on dark mode, I was browsing the code on themes > (in Moose 6.1 = Pharo 6.0, Latest update: #60486). In Class ThemeIcons, I > found this method: > > > > downloadTo: dir > > | zipArchive | > > > > zipArchive := self class destinationPath / (self name, > '.zip'). > > zipArchive exists > > ifFalse: [ > > ZnClient new > > url: self url; > > downloadTo: > zipArchive ]. > > > > ^ zipArchive > > > > The mystery is that the argument dir is not referred to anywhere in the > code. It probably works, because the only invocation of the method is from > ThemeIcons>>downloadFromUrl, which sets the argument from self class > destinationPath, and the code above recreates this as the path to > zipArchive. > > > > I thought I understood Smalltalk coding fairly well, but this really > puzzles me. Why would anyone code like this? Shouldnât it be picked up by a > code critic? Or am I going crazy? > > > > Any help gratefully received > > > > Peter Kenny >

Aug. 28, 2017

Code mystery

by PBKResearch

Hello All Following the discussion on dark mode, I was browsing the code on themes (in Moose 6.1 = Pharo 6.0, Latest update: #60486). In Class ThemeIcons, I found this method: downloadTo: dir | zipArchive | zipArchive := self class destinationPath / (self name, '.zip'). zipArchive exists ifFalse: [ ZnClient new url: self url; downloadTo: zipArchive ]. ^ zipArchive The mystery is that the argument dir is not referred to anywhere in the code. It probably works, because the only invocation of the method is from ThemeIcons>>downloadFromUrl, which sets the argument from self class destinationPath, and the code above recreates this as the path to zipArchive. I thought I understood Smalltalk coding fairly well, but this really puzzles me. Why would anyone code like this? Shouldn't it be picked up by a code critic? Or am I going crazy? Any help gratefully received Peter Kenny

Aug. 28, 2017

Re: [Pharo-users] How to create a minimal image ?

by Ben Coman

On Mon, Aug 28, 2017 at 9:32 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-08-28 13:33 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> for me Pharo and GUI go hand in hand, I cannot imagine Pharo without GUI. >> I also despise the command line. Plus once you remove the GUI you kill the >> very essence of Smalltalk. >> >> But if that is what you(you as all people who support this) like and >> need, that's your choice and I respect that. >> >> Even back in the 80s when almost everything was command lines , I was >> drooling over Amiga's 500 beautiful coloured GUIs. It started my >> fascination with computer graphics and later 3d graphics and sound. >> >> So me and the GUI are very old friends and we go hand in hand :) >> >> Of course I understand if we want to go super minimal the GUI has to go >> together with many other things that make Pharo what it is. But I dont care >> for such extremes. I just wanted to reduce the fat. >> > > We want Pharo without GUI to have better Pharo with GUI :-) > A super-simple-GUI in a minimal image step could later provide Emergency Tools facilities, so would not be redundant code (I've not been much successful using the current Emergency Evaluator.) Perhaps even a REPL like interface. Editing could be done in an external editor and pasted into the REPL in this form... . SomeClass>>#someMethod self doStuff. Are Bloc and Brick going to be loadable separately? How big is Bloc on its own? Would it (or some core subset of it) form a good basis for new Emergency Tools, or should they completely separate? A decision tree might be useful to see the overlap of different design options here showing the size of each bootstrap step. cheers -ben

Aug. 28, 2017

Re: [Pharo-users] constraining dragging movement of Morph Windows

by H. Hirzel

Hello Peter A hint, but not yet the solution World griddingOnOff. toggles the grid for morphs. World setGridSpec. Allows to set the grid. World griddingOn tells if the grid is on or off The commands above affect morphs, Morph new openInWorld but not the windows (Nautilus, Playground, ..., SystemWindow, ...) Something else in addition seems to be needed ...... Regards Hannes On 8/28/17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is it possible to somehow "constraint" the movement of windows (Nautilus, > Playground, ..., SystemWindow, ...)? > > E.g. I want for them to only move (or "snap") only at steps of e.g. 20 > pixels. > > So sort of snap-to-20-pixel-grid behavior. > > Thanks, > Peter >

Aug. 28, 2017