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

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

by Andreas Sunardi

That sounds good. Unfortunately for me, my work environment is using RedHat6/CentOS6 with glibc 2.12. Is there Pharo6 with glibc < 2.15 support. Or is there a way for me to build that myself? It's quite a departure to change my DSL into defining multiple methods. But that's my own problem. I'm happy to hear Pharo 6 can support a lot more literals. I tested my code on Pharo 6 (on my Windows box) and it works. I see SistaV1 compiler in Pharo 5 setting, but that causes Pharo to crash. Thank you guys for your answers. I think I have the information I need to make decision. But if there is a way to get Pharo 6 that works with glibc < 2.15, please let me know. Thank you -- Andreas On Tue, Aug 29, 2017 at 12:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 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] [Pillar] Pillar source code of ESUG 2015 presentation? Presentations done with Pillar?

by Peter UhnÃ¡k

All Pharo Mooc slides were made in pillar e.g. pillar: https://github.com/SquareBracketAssociates/PharoMooc/blob/master/Slides/Wee… output: http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Va… ( mooc.pharo.org ) Peter On Tue, Aug 29, 2017 at 2:54 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello > > On the slide 14 of the Pillar presentation at ESUG 2015 [1] it says > that the presentation was made with Pillar. Is the Pillar source code > available somewhere? > > Other source code examples of presentations made with Pillar are fine as > well. > > Thank you > > Hannes Hirzel > > > [1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630% > 20Pilar/Pillar.pdf > >

Aug. 29, 2017

[Pillar] Pillar source code of ESUG 2015 presentation? Presentations done with Pillar?

by H. Hirzel

Hello On the slide 14 of the Pillar presentation at ESUG 2015 [1] it says that the presentation was made with Pillar. Is the Pillar source code available somewhere? Other source code examples of presentations made with Pillar are fine as well. Thank you Hannes Hirzel [1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf

Aug. 29, 2017

Re: [Pharo-users] [Pillar] How do I open the Pillar editor in Pharo 6?

by H. Hirzel

On 8/28/17, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 26.08.2017 um 12:56 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> In an image having Pillar, inspect a Pillar file. Something like this: >> >> âpath/to/file.pillar' asFileReference >> > I downloaded a 6.1 image, loaded pillar from catalog and inspected > > 'foo.pillar' asFileReference > > and I get > The same result here. > > Looks like there are additional steps needed. > > Norbert > If I do PRPillarParser parse: 'myExample.pillar' asFileReference contents I get a nice display of the Pillar Document Object Model and the results after using different exporter objects (HTML, DeckJS, Markdown, AsciiDoc, Beamer, LaTeX) But no Pillar editor. --Hannes

Aug. 29, 2017

Re: [Pharo-users] The Spec UI Framework. first translation to korean finish.

by Damien Pollet

On 28 August 2017 at 06:34, peter yoo <onionmixer(a)gmail.com> wrote: > 1. failed to compile the SPEC UI Framework. Xetex would have caught the > error, but I do not know about luatex. > 2. I am using texlive 2017 with gentoo linux. Can you send me a copy of the error you are getting ? The English version should build fine on TeXlive 2017; however it might be that you're missing some packages or fonts, especially if you installed texlive from gentoo packages (maybe gentoo is different there, but Ubuntu requires optional packages to obtain a reasonably complete TeXlive. If it fails when you start including korean text in the book, then that's not entirely surprising. It could fail either at the pillar stage, or during the LaTeX compilation. Can you send us a copy of the compilation failure you are getting? > 3. In Korea, when making a book, in most cases it is using an oblivior > that has developed a memoir. > What do you mean by "oblivior"? What you meant has been lost in translationâ¦ are you talking about the memoir class from LaTeX ? > 4. In most cases, TeX is used to specify the font in consideration of the > CJK environment. > The books and booklets are based on https://github.com/cdlm/sbabook, which is a custom LaTeX class I wrote based on memoir.cls. Mostly it defines the typographic design and a few convenience commands and environments. It's certainly possible to make a few changes so that supports CJK. However I never used the CJK stuff in TeXlive, and I'm clueless about Korean typography etc, so it might lead to funny resultsâ¦ :) Anyway I will do some tests when I get the time. If you set some basics, I will join you in the future. However, I do not > know smacc, pillar, etc. > Ideally, you would write the translated-book using Pillar, in the same way we maintain the original in English, just in a branch or in a separate github repo. Editing the book directly in LaTeX is possible but then it means we can't compile it in web formâ¦ Cheers

Aug. 29, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tudor Girba

> On Aug 29, 2017, at 12:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > The code works fine in Pharo 7.0. I just tried the following: > 1. wget -O- get.pharo.org/alpha+vm | bash > > Ah, sorry. I always forgot update. No problem. I am happy that it works :). Doru > > 2. > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load > 3. > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference > Cheers, > Doru > > 2017-08-29 11:32 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Denis, > > Thanks for the feedback! > > As I mentioned, this is a pre-alpha :). Our main focus was on exploring that the design works in breadth. There are indeed, detailed issues that do not work yet, and there are edge cases for navigation and insertion/deletion that are still open issues. > > In Bloc we intentionally have not focused on error catching yet. So, right now when there is an error during layout or rendering, Bloc can get in a funny state. You can reset Bloc with: > BlUniverse reset > > The code works fine in Pharo 7.0. I just tried the following: > > 1. wget -O- get.pharo.org/alpha+vm | bash > 2. > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load > 3. > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference > > Cheers, > Doru > > > > > On Aug 29, 2017, at 11:04 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Hi > > > > I have bad feedback. I guess work is still in progress. > > > > So basic cursor navigation is still not working fine: > > - sometimes cmd+arrow up is not working and cursor disappears. > > - scrolling feels slow and not smooth. > > After attempt to edit text (just press key) I got assertion failures about some layout problems. And after reopening inspector the bloc pillar tab was empty. > > > > When you are expecting stable version? > > Should it works better in "native" Bloc window (without morphic)? And how to open example this way? > > > > Also it not loads well in Pharo 7 and not working there. > > My feedback from Pharo 6 on MacOS > > > > 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. > > > > To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. > > > > Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. > > > > <pillar-mondrian-examples.png> > > > > Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). > > > > <pillar-mondrian-expanded-preview.png> > > > > Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). > > > > A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. > > > > Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. > > > > We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. > > > > All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > > > Iceberg enableMetacelloIntegration: true. > > Metacello new > > baseline: 'GToolkit'; > > repository: 'github://feenkcom/gtoolkit/src'; > > load. > > > > And then inspect: > > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference > > > > Cheers, > > The feenk team > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Innovation comes in the least expected form. > > That is, if it is expected, it already happened." > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > > -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Aug. 29, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Denis Kudriashov

> > The code works fine in Pharo 7.0. I just tried the following: > 1. wget -O- get.pharo.org/alpha+vm | bash > Ah, sorry. I always forgot update. > 2. > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load > 3. > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > Cheers, > Doru 2017-08-29 11:32 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Denis, > > Thanks for the feedback! > > As I mentioned, this is a pre-alpha :). Our main focus was on exploring > that the design works in breadth. There are indeed, detailed issues that do > not work yet, and there are edge cases for navigation and > insertion/deletion that are still open issues. > > In Bloc we intentionally have not focused on error catching yet. So, right > now when there is an error during layout or rendering, Bloc can get in a > funny state. You can reset Bloc with: > BlUniverse reset > > The code works fine in Pharo 7.0. I just tried the following: > > 1. wget -O- get.pharo.org/alpha+vm | bash > 2. > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load > 3. > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > > Cheers, > Doru > > > > > On Aug 29, 2017, at 11:04 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > Hi > > > > I have bad feedback. I guess work is still in progress. > > > > So basic cursor navigation is still not working fine: > > - sometimes cmd+arrow up is not working and cursor disappears. > > - scrolling feels slow and not smooth. > > After attempt to edit text (just press key) I got assertion failures > about some layout problems. And after reopening inspector the bloc pillar > tab was empty. > > > > When you are expecting stable version? > > Should it works better in "native" Bloc window (without morphic)? And > how to open example this way? > > > > Also it not loads well in Pharo 7 and not working there. > > My feedback from Pharo 6 on MacOS > > > > 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > We are really pleased to announce another major advancement in the > development of the moldable editor, and most of it was enabled because of > one new feature: expandable elements. We think this will impact > significantly our day to day interactions. > > > > To exemplify what we mean, we will make use of two more alpha projects > that we did not announce yet: GT Documenter (a set of documentation tools > based on Pillar and GT Examples) and GT Mondrian (the graph visualization > engine), both of which are being implemented in Bloc. > > > > Please take a look at the following pictures showing the documentation > Pillar file that ships together with GT Mondrian. What stands out are the > two embedded pictures. These are actually not pictures, but visualizations > rendered live during the viewing of the document out of a referenced GT > Example. > > > > <pillar-mondrian-examples.png> > > > > Now, GT Examples are likely also new for most people. We introduced them > a couple of years ago based on the original idea of Markus Gaelli. These > are a kind of tests that return an object and that can be built out of > other examples. The nice thing is that they are always executable and > testable. So, of course, if you see the resulting object, you can also see > the code that created it, and if you see the code, you can even execute it > live, right in place (notice the preview of the second snippet). > > > > <pillar-mondrian-expanded-preview.png> > > > > Perhaps the most controversial part of GT Examples is that they offer a > mechanism to define static dependencies via pragmas. Please, letâs leave > this debate to another occasion, but please also notice that tools can use > that static information to unfold the code of the referenced method (notice > the nested code editors). > > > > A side note: if you look closer at the list with three items at the top > of the Tutorial section, you will notice numbering next to #. That is > actually syntax highlighting and so is the mechanism that embeds the > expandable elements. Itâs really cool. > > > > Taking step back, when we introduced the editor a few weeks ago, we > called it moldable because we said we can make it take different shapes > easily. GT Documenter with everything you see in the above screenshots has > currently ~500 lines of code, and all this while still having an editor > that is highly scalable. > > > > We think that Bloc and Brick will change dramatically face of Pharo and > now we can start to get a glimpse of what is possible. For example, the use > case presented above is more than a technical tool, and we think this will > change both the way we write documentation and the way we consume it. > > > > All these will be presented at ESUG both during presentations and at the > Innovation Awards competition. In the meantime, those that want to play > with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > > > Iceberg enableMetacelloIntegration: true. > > Metacello new > > baseline: 'GToolkit'; > > repository: 'github://feenkcom/gtoolkit/src'; > > load. > > > > And then inspect: > > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > > > > Cheers, > > The feenk team > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Innovation comes in the least expected form. > > That is, if it is expected, it already happened." > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > >

Aug. 29, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tudor Girba

Hi Denis, Thanks for the feedback! As I mentioned, this is a pre-alpha :). Our main focus was on exploring that the design works in breadth. There are indeed, detailed issues that do not work yet, and there are edge cases for navigation and insertion/deletion that are still open issues. In Bloc we intentionally have not focused on error catching yet. So, right now when there is an error during layout or rendering, Bloc can get in a funny state. You can reset Bloc with: BlUniverse reset The code works fine in Pharo 7.0. I just tried the following: 1. wget -O- get.pharo.org/alpha+vm | bash 2. Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load 3. './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference Cheers, Doru > On Aug 29, 2017, at 11:04 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi > > I have bad feedback. I guess work is still in progress. > > So basic cursor navigation is still not working fine: > - sometimes cmd+arrow up is not working and cursor disappears. > - scrolling feels slow and not smooth. > After attempt to edit text (just press key) I got assertion failures about some layout problems. And after reopening inspector the bloc pillar tab was empty. > > When you are expecting stable version? > Should it works better in "native" Bloc window (without morphic)? And how to open example this way? > > Also it not loads well in Pharo 7 and not working there. > My feedback from Pharo 6 on MacOS > > 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. > > To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. > > Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. > > <pillar-mondrian-examples.png> > > Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). > > <pillar-mondrian-expanded-preview.png> > > Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). > > A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. > > Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. > > We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. > > All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > And then inspect: > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference > > Cheers, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Aug. 29, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Denis Kudriashov

Hi I have bad feedback. I guess work is still in progress. So basic cursor navigation is still not working fine: - sometimes cmd+arrow up is not working and cursor disappears. - scrolling feels slow and not smooth. After attempt to edit text (just press key) I got assertion failures about some layout problems. And after reopening inspector the bloc pillar tab was empty. When you are expecting stable version? Should it works better in "native" Bloc window (without morphic)? And how to open example this way? Also it not loads well in Pharo 7 and not working there. My feedback from Pharo 6 on MacOS 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are really pleased to announce another major advancement in the > development of the moldable editor, and most of it was enabled because of > one new feature: expandable elements. We think this will impact > significantly our day to day interactions. > > To exemplify what we mean, we will make use of two more alpha projects > that we did not announce yet: GT Documenter (a set of documentation tools > based on Pillar and GT Examples) and GT Mondrian (the graph visualization > engine), both of which are being implemented in Bloc. > > Please take a look at the following pictures showing the documentation > Pillar file that ships together with GT Mondrian. What stands out are the > two embedded pictures. These are actually not pictures, but > visualizations rendered live during the viewing of the document out of a > referenced GT Example. > > > Now, GT Examples are likely also new for most people. We introduced them a > couple of years ago based on the original idea of Markus Gaelli. These are > a kind of tests that return an object and that can be built out of other > examples. The nice thing is that they are always executable and testable. > So, of course, if you see the resulting object, you can also see the code > that created it, and if you see the code, you can even execute it live, > right in place (notice the preview of the second snippet). > > > Perhaps the most controversial part of GT Examples is that they offer a > mechanism to define static dependencies via pragmas. Please, letâs leave > this debate to another occasion, but please also notice that tools can use > that static information to unfold the code of the referenced method (notice > the nested code editors). > > A side note: if you look closer at the list with three items at the top of > the Tutorial section, you will notice numbering next to #. That is actually > syntax highlighting and so is the mechanism that embeds the expandable > elements. Itâs really cool. > > Taking step back, when we introduced the editor a few weeks ago, we called > it moldable because we said we can make it take different shapes easily. GT > Documenter with everything you see in the above screenshots has currently > ~500 lines of code, and all this while still having an editor that is > highly scalable. > > We think that Bloc and Brick will change dramatically face of Pharo and > now we can start to get a glimpse of what is possible. For example, the use > case presented above is more than a technical tool, and we think this will > change both the way we write documentation and the way we consume it. > > All these will be presented at ESUG both during presentations and at the > Innovation Awards competition. In the meantime, those that want to play > with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > And then inspect: > './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > > Cheers, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > >

Aug. 29, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

"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..." You mean he was embarrassed to admit he could not read small fonts ? How small we talking here bellow 12 point size ? On Tue, Aug 29, 2017 at 11:28 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > 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