- Pharo-users - lists.pharo.org

Re: [Pharo-users] Dark Mode

by PBKResearch

I agree with Dimitris - it is all a matter of preference - not all eyes are the same. For myself, I find the default dark theme in Pharo very uncomfortable. On my system, some elements have a black foreground on a dark grey background, which is almost impossible to see. This is always true of the maximise/minimise/close buttons, but sometimes also of text fields in a playground. Whenever I download a new image, I immediately switch to the Watery theme, with light background and nice coloured buttons on the windows. Of course, my eyes may not be typical. I am now aged 84, and I have had cataract operations on both eyes. My sight is actually quite good - my optometrist confirms that I am legal to drive without spectacles - but my adverse reaction to dark mode is strong and immediate. Just my 2p worth Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of stephan Sent: 27 August 2017 21:46 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Dark Mode On 27-08-17 22:37, Dimitris Chloupis wrote: > White or dark is a matter of preference. But the matter of preference > is also a matter of biology . Not all eyes are same. The research is pretty clear: a large majority of developers does better with light themes. I have been sufficiently clear on the choice to make Pharo6 theme dark default Stephan

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

no offence my friend, even when i did not understand the joke. I am completely respectful of the people who find it hard to work with a dark theme and I always stated that Pharo should have both, ideally ever more themes. Of course we don't have the size of the community to do that. Ideally Pharo could offer the choice at welcome screen but to be fair to devs its super easy to change it, a couple of clicks away. Light theme definitely wont go anywhere , which one is more popular is not really my point and frankly it does not matter both of them have quite a large following and its great we have them both in image. If we want people to love Pharo then we have to accept that each person has it own preferences and sometime its for good reason like eye strain. I am definitely a big defender of choice , after all my theme has that as a feature ;) I suspect dark monitor may have been an energy issue. Another issue is that back then monitors were CRT and there was actual radiation that affected the eye. For example my monitor was making my eyes seeing things pink for a while till my eye rested. It may have been the green color. I remember my glasses even came with layers specialised to reflect some of the radiation and it actually helped a bit. On the other hand bright themes did emerge at the time of window 3.1 and of course we still had CRT monitors so you may be correct and it was mainly a energy consumption issue. I simply dont know, life tends to be appear simple , but alas its far from it :D On Mon, Aug 28, 2017 at 12:24 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Dimitris, > > On Sun, Aug 27, 2017 at 08:37:56PM +0000, Dimitris Chloupis wrote: > > > > I completely agree - dark mode is great for content that you want to > > look cool, but no one consumes. :-) > > I actually meant this in jest, which is why it has the smiley face > afterwords. > > I don't know which is more popular, light or dark themes, I'm glad that > Pharo makes it easy to automatically change to which ever one prefers - > which was what the code following this sentence was demonstrating. > > > > You assume wrong cause dark themes have been dominating GUIs for over 3 > decades > > now. 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. > > > > My first computer was black background with green fonts, black back in > 80 and > > 90s was pretty much the norm. There was no white or bright themes back > then. It > > was not because the monitors had any issues with displaying white. > > I had my terminals set to black background with green fonts up to last > year since that is what I was used to from my Dick Smith System 80 > (TRS-80 clone). :-) > > Going slightly off topic: I suspect terminals used a dark theme by > default because a light theme would burn out the CRT. If I remember > correctly, DEC VT-220's had a light theme (which I didn't use). > > > > It was actually the web that made white a thing. Probably inexperienced > web > > coders (there were no web devs back then ) thought it made sense > transitioning > > from paper. Problem is that paper , reflects light, does not emit it. > > > > White or dark is a matter of preference. But the matter of preference is > also a > > matter of biology . Not all eyes are same. Some eyes have hard time > > distinguishing elements in dark environments , others have hard time > > distinguishing elements in bright environments but excel at dark > environments. > > I belong to the second case as such white themes for me are pretty much > > unacceptable for any content I have to read for a long time. > > > > My monitor as we speak is set to 1/16th of its brightness which is the > minimum > > setting. During the day that sun goes in my room it goes up to 3/16 > maximum. > > Above that I am forced to simply reduce the light in the room. > > > > Trying to use Moose especially that was even brighter it was even harder > for me > > to the point I gave up and never used it since then. > > > > So yes there are many of us who were raised with dark themes, still use > dark > > themes , will continue to use dark themes and criticise any app that > does not > > support them. For me the Dark theme has been the most important > improvement of > > Pharo and I am not exaggerating one tiny bit. > > I largely agree with what you've said. My eyes have just deteriorated > in the opposite direction - I can't read with a dark theme (my terminals > are now dark text on a white background). > > My apologies for any offence, it wasn't intended. > > > Cheers, > Alistair > > >

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Alistair Grant

Hi Dimitris, On Sun, Aug 27, 2017 at 08:37:56PM +0000, Dimitris Chloupis wrote: > > I completely agree - dark mode is great for content that you want to > look cool, but no one consumes. :-) I actually meant this in jest, which is why it has the smiley face afterwords. I don't know which is more popular, light or dark themes, I'm glad that Pharo makes it easy to automatically change to which ever one prefers - which was what the code following this sentence was demonstrating. > You assume wrong cause dark themes have been dominating GUIs for over 3 decades > now. 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. > > My first computer was black background with green fonts, black back in 80 and > 90s was pretty much the norm. There was no white or bright themes back then. It > was not because the monitors had any issues with displaying white. I had my terminals set to black background with green fonts up to last year since that is what I was used to from my Dick Smith System 80 (TRS-80 clone). :-) Going slightly off topic: I suspect terminals used a dark theme by default because a light theme would burn out the CRT. If I remember correctly, DEC VT-220's had a light theme (which I didn't use). > It was actually the web that made white a thing. Probably inexperienced web > coders (there were no web devs back then ) thought it made sense transitioning > from paper. Problem is that paper , reflects light, does not emit it. > > White or dark is a matter of preference. But the matter of preference is also a > matter of biology . Not all eyes are same. Some eyes have hard time > distinguishing elements in dark environments , others have hard time > distinguishing elements in bright environments but excel at dark environments. > I belong to the second case as such white themes for me are pretty much > unacceptable for any content I have to read for a long time. > > My monitor as we speak is set to 1/16th of its brightness which is the minimum > setting. During the day that sun goes in my room it goes up to 3/16 maximum. > Above that I am forced to simply reduce the light in the room. > > Trying to use Moose especially that was even brighter it was even harder for me > to the point I gave up and never used it since then. > > So yes there are many of us who were raised with dark themes, still use dark > themes , will continue to use dark themes and criticise any app that does not > support them. For me the Dark theme has been the most important improvement of > Pharo and I am not exaggerating one tiny bit. I largely agree with what you've said. My eyes have just deteriorated in the opposite direction - I can't read with a dark theme (my terminals are now dark text on a white background). My apologies for any offence, it wasn't intended. Cheers, Alistair

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

what research institute reached that conclusion the same institute that claims that Pharo and Git cannot mix ? Please say to your institute to do a simple search on google search and put two words "code editor" and then click the "images" section and then say hello to reality. In the first 40 most popular results only 2 use a light theme. The rest of results is 60/40 dark/light. We agree one things though, its definitely sufficiently clear which one is the most popular. On Sun, Aug 27, 2017 at 11:47 PM stephan <stephan(a)stack.nl> wrote: > On 27-08-17 22:37, Dimitris Chloupis wrote: > > White or dark is a matter of preference. But the matter of preference is > > also a matter of biology . Not all eyes are same. > > The research is pretty clear: a large majority of developers does better > with light themes. I have been sufficiently clear on the choice to make > Pharo6 theme dark default > > Stephan > > >

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by stephan

On 27-08-17 22:37, Dimitris Chloupis wrote: > White or dark is a matter of preference. But the matter of preference is > also a matter of biology . Not all eyes are same. The research is pretty clear: a large majority of developers does better with light themes. I have been sufficiently clear on the choice to make Pharo6 theme dark default Stephan

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

> Kilon has blue-ish theme (I don't think he published it anywhere), > The theme is called Nireas , its a dark theme based on blue color and is inspired by the best computer of all time. Amiga 500. Nireas is also a special theme because its a themable theme. It comes with a GUI that allows you to change its colors very easily to whatever you like. Should have probably named it "Chameleon" ;) I was planning to create also a preset system for it but I have been so happy with the blue theme that I never bothered it , together with the fact that none shown an actual interest in having a theme creation GUI. Of course people think its a cool idea, but I am talking here actual help, not words. Its super easy to get Nireas, it installs with a single click from the Package Browser from inside the image , like you install many other things. Its tested with each version because well, I always use the latest version of Pharo and there is close to zero reason why it would not work other than someone actually changing the theme classes. Of course its hosted on Github https://github.com/kilon/Nireas

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

> > > 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. 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. My first computer was black background with green fonts, black back in 80 and 90s was pretty much the norm. There was no white or bright themes back then. It was not because the monitors had any issues with displaying white. It was actually the web that made white a thing. Probably inexperienced web coders (there were no web devs back then ) thought it made sense transitioning from paper. Problem is that paper , reflects light, does not emit it. White or dark is a matter of preference. But the matter of preference is also a matter of biology . Not all eyes are same. Some eyes have hard time distinguishing elements in dark environments , others have hard time distinguishing elements in bright environments but excel at dark environments. I belong to the second case as such white themes for me are pretty much unacceptable for any content I have to read for a long time. My monitor as we speak is set to 1/16th of its brightness which is the minimum setting. During the day that sun goes in my room it goes up to 3/16 maximum. Above that I am forced to simply reduce the light in the room. Trying to use Moose especially that was even brighter it was even harder for me to the point I gave up and never used it since then. So yes there are many of us who were raised with dark themes, still use dark themes , will continue to use dark themes and criticise any app that does not support them. For me the Dark theme has been the most important improvement of Pharo and I am not exaggerating one tiny bit.

Aug. 27, 2017

Re: [Pharo-users] pillar image in external link (or html a tag)

by Peter UhnÃ¡k

I did a pass on the Markdown exporter to align it with CommonMark specifications, so it is exporter properly if I instantiate the objects. But Pillar also needs to parse the string properly. On Sun, Aug 27, 2017 at 8:28 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi peter > > I do not think you can. I learned this features friday while writing > md text to point to travis. > This is something that we will able to add but for now my focus is not > there. > Stef > > On Sat, Aug 26, 2017 at 10:41 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > > > how can I embed an image into an anchor in Pillar? > > > > I've tried > > > > *+Pharo>https://pharo.org/web/files/pharo.png+>http://pharo.org/* > > > > I've also tried to create document by hand and export it, but every > single > > exporter failed on it. > > > > doc := PRDocument new > > add: (PRExternalLink new > > reference: 'http://pharo.org/'; > > add: (PRFigure new > > reference: 'https://pharo.org/web/files/pharo.png'; > > add: (PRText content: 'Pharo'); > > yourself > > ); > > yourself > > ); > > yourself > > > > Thanks, > > Peter > >

Aug. 27, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Stephane Ducasse

> About deprecation, I found it fast because I think FFI as a key component of > a language. I imagine similar problems could happen when going from Morphic > to its successor (Bloc?). Even with a stable API, I expect some code to > explicitely depends on Morphic and break in the next GUI framework. I do not > think this can be avoided. I am aware that maintenance is very costly and > that it is always hard to be sure new users do not get caught in this kind > of change. (As far as I understand the old MVC framework was kept quite long > along with the at-the-time new Morphic to ensure smooth transition.) For Morphic I think that we will see but Bloc should not be killed on the altar of Morphic compatibility. We do not have much to keep from Morphic. > > Note that I am not trying to claim that Pharo generally is bad or worse than > another language. As a new user, my expectations were quite high after > spending a few weeks learning the language, going through the MOOC, being > able to tinker with the UI (looking at everything, modifying the World Menu, > etc.), looking into the details of the bytecode and the VM. All of these > worked very well and I still do think that Pharo is a great of software as I > wrote in a previous question. Even when facing the UI problem in Pharo 5 due > to old FFI syntax, I was able to hack into the code and get it work. In > another language hitting an "internal" problem often is a dead end. > > I cannot tackle the problems I highlighted by myself. But with the help of > someone who knows how to address them in the Pharo's way, I am willing to > help. Esteban told me that it was decided that the parser was not maintain for the ffi. Now what would be great is to port the library to Pharo and newFFI. > About dependencies and version, I knew of Metacello configurations when I > wrote my first message and I was thinking of Pharo version (more precisely > the versions of core packages and dependencies as opposed to other external > packages that should be loaded on top of a freshly downloaded image). > I did not know that Pharo version was in configurations. So I had a look at > ConfigurationOfZeroMQ and maybe it keeps on being an exception but I did not > find any dependency on Pharo version in it. it is normal because we do not have yet metadata for loaded packages However it declares a dependency > on FFI version 1.4, which eventually is better than explicitely setting a > dependency on a Pharo version. I also had a look at the "validate" class > method and its comment that mentions "MetacelloMCVersionValidator". How is > this validation mechanism triggered? I could work on it and modify the > source code loader(s) so that instead of getting a syntax error in Pharo 6 I > get an error or a critical warning from the validator. (I loaded the package > by adding the corresponding repository in the Monticello browser and loading > ZeroMQ and ConfigurationOfZeroMQ last versions.) > > I eventually found what you talked about. In ConfigurationOfFFI, "stable:" > method lists the FFI versions that Pharo versions supports. The convention > for versioning is not clear to me: old FFI is supposed to work up to Pharo 4 > and the spec says FFI should be 1.7 to 1.9, which would mean that if a > package needs version x, any version y>=x is ok, but from Pharo 5 (which > requires FFI 1.10.1) it should fail, which would mean that version x should > be matched exactly (or an interval should be defined). > In Pharo 6 ConfigurationOfUnifiedFFI>>version_0_26_8 declares a dependency > on FFI-Kernel âFFI-Kernel-EstebanLorenzano.45â, which I do not understand. > Maybe here I can remove FFI dependencies. (Is this what you meant when > saying you could have deprecated it but did not do it?) > Besides ConfigurationOfFFI is not included in a freshly downloaded Pharo > image (I checked for Pharo 5), I found a reference to it in > ConfigurationOfUnifiedFFI (in the "ffi:" method) and manually added the > corresponding repository (MetaRepoForPharo50) in Monticello browser and > loaded the last version of ConfigurationOfFFI. So it seems that the info is > not available by default. That I do not know :) > I had also a look at FFI-Kernel package (the object as found by running > "RPackageOrganizer default packages select: [:p | p name = #'FFI-Kernelâ].") > and could not find any version info. Is it correct that the version info of > a package is only available through ConfigurationOf... and is not included > in the package object? > > If I understand well, a way to correct the problem would be: > - to ensure (or set it as an option for a start) that Metacello validation > is triggered even when loading source code and let the user choose from an > option whether it wants errors at loading stage or only warnings (and expect > problems when running). > - add all the ConfigurationOf that are in "Pharo/MetaRepoForPharo50/main" > repository in the corresponding official image (maybe rather do this for > Pharo60 which is still maintained) so that the validation gets all the > needed info > - as you mentioned in an earlier message ConfigurationOf for some "internal" > packages (included in a freshly downloaded Pharo image) are missing, so add > them, attribute them a version and set dependencies accordingly. (I can > help, it is a good way to learn about the internals of the language.) > Is it correct? (I can also work on the validator with some help.) I do not know . What I would do for now is - port the library to latest Pharo stable - make sure that you are succesful with your project - Of course you can help by fixing some aspects of Pharo you want to see improved :) I hope that we will deliver package metadata and the tooling. > > About correcting the specific problem I had in Pharo 5. Esteban told me that > it was not useful so I am confused now. > > About 0mq, I am not an expert of the (original) C library and of the python > bindings. The library sets up sockets for communication between processes > and even if you can serialize them apparently ZeroMQ is relatively brittle > as regards initialization (and this is one of its flaws). The author of the > ZeroMQ Pharo package was aware of the persistence problem and mentioned he > could not solve it completely. This is not an easy problem apparently. > About python bindings, they abstract initialization a bit and more > importantly offer abstractions to process the messages through the sockets: > integration with the async python 3 framework and with a popular event loop > (python tornado library from Facebook) are offered. It is much easier to > work with ZeroMQ this way as you do not have to care about low-level IO > details. (I do not know how it is done in the python bindings but for > example to listen to the socket either an event loop could take care of the > regular polling of the sockets or one could set up a thread that listens to > the socket through a blocking call.) Thanks for the description. > The equivalent in Pharo might be to integrate ZeroMQ with the GUI event > loop. (Not something I am able to do unfortunately.) > > Thanks, > Bruno > > > > -- > View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 27, 2017

Re: [Pharo-users] pillar image in external link (or html a tag)

by Stephane Ducasse

Hi peter I do not think you can. I learned this features friday while writing md text to point to travis. This is something that we will able to add but for now my focus is not there. Stef On Sat, Aug 26, 2017 at 10:41 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > how can I embed an image into an anchor in Pillar? > > I've tried > > *+Pharo>https://pharo.org/web/files/pharo.png+>http://pharo.org/* > > I've also tried to create document by hand and export it, but every single > exporter failed on it. > > doc := PRDocument new > add: (PRExternalLink new > reference: 'http://pharo.org/'; > add: (PRFigure new > reference: 'https://pharo.org/web/files/pharo.png'; > add: (PRText content: 'Pharo'); > yourself > ); > yourself > ); > yourself > > Thanks, > Peter

Aug. 27, 2017