February 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 60 needs help on shortcuts-are-wrongly-displayed

by Stephane Ducasse

Ok let us close the bug entry. One less to go. Stef On Tue, Feb 7, 2017 at 11:24 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > I back up Pavel and Esteban here. > > On Tue, Feb 7, 2017 at 11:18 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> On 7 Feb 2017, at 10:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> The uperchase character is the symbol on the key. >> >> In OS X the uppercase characters are used: >> http://cdn.osxdaily.com/wp-content/uploads/2011/07/access- >> library-lion.jpg >> >> In Chrome too: >> http://addoncrop.com/cdn/2014/12/Google-Chrome-Menu-Settions-option.png >> >> On Windows too: >> http://www.howtogeek.com/wp-content/uploads/2012/03/650x250x >> context-menu-shortcuts-header.png.pagespeed.gp+jp+jw+pj+js+ >> rj+rp+rw+ri+cp+md.ic.SuZmOlpqkt.png >> >> Cheers, >> -- Pavel >> >> 2017-02-06 17:57 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed >>> >>> The system should display Ctrl + s and not Ctrl + S >>> >>> Because people are pressing Shift to get S and this is not working. >>> We should distinguish between uppercase and lowercase. >>> The reader cannot guess that S is not the same as s + shift. >>> There is no way that a user can know that they should NOT press shift >>> when looking at Ctrl + S (because there is no noshiftPressed). >>> Ctrl + S means press Shift. >>> >> >> >> key shorcuts are for key, not for character, thatâs why they point to the >> key in the keyboard. >> this is the universal standard, so I do not think we need to change it. >> >> as Pavel explain, is like that : >> >> - on mac: symbols + key >> - on linux and windows: modifiers + key (e.g. "Shift + S", "Ctrl + Shift >> + S") >> >> cheers, >> Esteban >> >> >> >

Feb. 7, 2017

Re: [Pharo-dev] Pharo 60 need help white-theme-color-for-button-is-not-good

by Stephane Ducasse

Thanks this is important :) On Tue, Feb 7, 2017 at 11:36 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Feb 7, 2017 at 8:07 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> No it is important. >> There is no point to have a supercool system that looks so bad and turn >> people off. >> > > I agree to that. Skinning/Theming should be an important thing. > > I am working on Sublimish because it reveals a lot of things that are not > in sync between GToolkit bits and Pharo standard bits (well, GT is now > Pharo standard but still). See various grays/jungle grays discrepancy > because of hardcoded things instead of having a ThemePalette thing (I do > have one working for my local stuff, one I get the theme correct in full, > I'll put it in the catalog of 5.0). > > [image: Inline image 2] > > > >> But I do not get it your 13136 was integrated. >> > > Not in the way I wanted it. Scrollbar thumb is still needing a click to > see it in light theme. I can have a look. > >> >> >> >> On Mon, Feb 6, 2017 at 6:28 PM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> I proposed that a while ago because these gradients are bad looking >>> (especially in an age of flat design). >>> >>> https://pharo.fogbugz.com/f/cases/13132/Ugly-gradients-in-Ph >>> aro3Theme-Not-in-line-with-the-times >>> >>> Same for those ugly flat scrollbars. >>> >>> https://pharo.fogbugz.com/f/cases/13136/Pharo3Theme-scrollba >>> rs-looking-like-dead-without-visual-indicators >>> >>> This one has a slice. >>> >>> Maybe Pharo 6 is not too late for those slices. >>> >>> Phil >>> >>> >>> >>> On Mon, Feb 6, 2017 at 5:59 PM, Stephane Ducasse < >>> stepharo.self(a)gmail.com> wrote: >>> >>>> https://pharo.fogbugz.com/f/cases/19657/white-theme-color-fo >>>> r-button-is-not-good >>>> >>>> If we compare the selection color for the dark theme, the blue is >>>> stronger and much better to see. >>>> This is particularly true for class/instance side button, >>>> >>>> I would be good to have a better white theme with stronger selection >>>> colors. >>>> >>> >>> >> >

Feb. 7, 2017

Pharo 60 needs help because Removing-a-package-with-extensions-let-the-extensions-in-the-system-and-break-their-reload

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/19664/Removing-a-package-with-extensions-…

Feb. 7, 2017

Re: [Pharo-dev] Pharo 60 need help white-theme-color-for-button-is-not-good

by phil＠highoctane.be

On Tue, Feb 7, 2017 at 8:07 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > No it is important. > There is no point to have a supercool system that looks so bad and turn > people off. > I agree to that. Skinning/Theming should be an important thing. I am working on Sublimish because it reveals a lot of things that are not in sync between GToolkit bits and Pharo standard bits (well, GT is now Pharo standard but still). See various grays/jungle grays discrepancy because of hardcoded things instead of having a ThemePalette thing (I do have one working for my local stuff, one I get the theme correct in full, I'll put it in the catalog of 5.0). [image: Inline image 2] > But I do not get it your 13136 was integrated. > Not in the way I wanted it. Scrollbar thumb is still needing a click to see it in light theme. I can have a look. > > > > On Mon, Feb 6, 2017 at 6:28 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> I proposed that a while ago because these gradients are bad looking >> (especially in an age of flat design). >> >> https://pharo.fogbugz.com/f/cases/13132/Ugly-gradients-in-Ph >> aro3Theme-Not-in-line-with-the-times >> >> Same for those ugly flat scrollbars. >> >> https://pharo.fogbugz.com/f/cases/13136/Pharo3Theme-scrollba >> rs-looking-like-dead-without-visual-indicators >> >> This one has a slice. >> >> Maybe Pharo 6 is not too late for those slices. >> >> Phil >> >> >> >> On Mon, Feb 6, 2017 at 5:59 PM, Stephane Ducasse <stepharo.self(a)gmail.com >> > wrote: >> >>> https://pharo.fogbugz.com/f/cases/19657/white-theme-color-fo >>> r-button-is-not-good >>> >>> If we compare the selection color for the dark theme, the blue is >>> stronger and much better to see. >>> This is particularly true for class/instance side button, >>> >>> I would be good to have a better white theme with stronger selection >>> colors. >>> >> >> >

Feb. 7, 2017

Re: [Pharo-dev] Pharo 60 needs help on shortcuts-are-wrongly-displayed

by Guillermo Polito

I back up Pavel and Esteban here. On Tue, Feb 7, 2017 at 11:18 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 7 Feb 2017, at 10:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > The uperchase character is the symbol on the key. > > In OS X the uppercase characters are used: > http://cdn.osxdaily.com/wp-content/uploads/2011/07/access-library-lion.jpg > > In Chrome too: > http://addoncrop.com/cdn/2014/12/Google-Chrome-Menu-Settions-option.png > > On Windows too: > http://www.howtogeek.com/wp-content/uploads/2012/03/650x250xcontext-menu- > shortcuts-header.png.pagespeed.gp+jp+jw+pj+js+rj+ > rp+rw+ri+cp+md.ic.SuZmOlpqkt.png > > Cheers, > -- Pavel > > 2017-02-06 17:57 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed >> >> The system should display Ctrl + s and not Ctrl + S >> >> Because people are pressing Shift to get S and this is not working. >> We should distinguish between uppercase and lowercase. >> The reader cannot guess that S is not the same as s + shift. >> There is no way that a user can know that they should NOT press shift >> when looking at Ctrl + S (because there is no noshiftPressed). >> Ctrl + S means press Shift. >> > > > key shorcuts are for key, not for character, thatâs why they point to the > key in the keyboard. > this is the universal standard, so I do not think we need to change it. > > as Pavel explain, is like that : > > - on mac: symbols + key > - on linux and windows: modifiers + key (e.g. "Shift + S", "Ctrl + Shift + > S") > > cheers, > Esteban > > >

Feb. 7, 2017

Re: [Pharo-dev] Pharo 60 needs help on shortcuts-are-wrongly-displayed

by Esteban Lorenzano

> On 7 Feb 2017, at 10:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > The uperchase character is the symbol on the key. > > In OS X the uppercase characters are used: > http://cdn.osxdaily.com/wp-content/uploads/2011/07/access-library-lion.jpg <http://cdn.osxdaily.com/wp-content/uploads/2011/07/access-library-lion.jpg> > > In Chrome too: > http://addoncrop.com/cdn/2014/12/Google-Chrome-Menu-Settions-option.png <http://addoncrop.com/cdn/2014/12/Google-Chrome-Menu-Settions-option.png> > > On Windows too: > http://www.howtogeek.com/wp-content/uploads/2012/03/650x250xcontext-menu-sh… <http://www.howtogeek.com/wp-content/uploads/2012/03/650x250xcontext-menu-sh…> > > Cheers, > -- Pavel > > 2017-02-06 17:57 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed <https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed> > > The system should display Ctrl + s and not Ctrl + S > > Because people are pressing Shift to get S and this is not working. > We should distinguish between uppercase and lowercase. > The reader cannot guess that S is not the same as s + shift. > There is no way that a user can know that they should NOT press shift when looking at Ctrl + S (because there is no noshiftPressed). > Ctrl + S means press Shift. > key shorcuts are for key, not for character, thatâs why they point to the key in the keyboard. this is the universal standard, so I do not think we need to change it. as Pavel explain, is like that : - on mac: symbols + key - on linux and windows: modifiers + key (e.g. "Shift + S", "Ctrl + Shift + S") cheers, Esteban

Feb. 7, 2017

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by Sven Van Caekenberghe

OK, I committed the following in Zn #bleedingEdge: === Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.46 Author: SvenVanCaekenberghe Time: 7 February 2017, 11:07:31.306364 am UUID: a2928299-1dda-4fdf-b15e-e5d7bed2373e Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.45 Add ZnCharacterEncoder class>>#knownEncodingIdentifiers to return the collection of all known encoding identifiers in the system - thx Nicolai Hess for the request Make sure #null is resolved to ZnNullEncoder Add ZnCharacterEncoderTests>>#testKnownEncodingIdentifiers === Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.28 Author: SvenVanCaekenberghe Time: 7 February 2017, 11:07:50.782471 am UUID: 938d1683-b8c4-4861-b1e1-f876b57405ef Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.27 Add ZnCharacterEncoder class>>#knownEncodingIdentifiers to return the collection of all known encoding identifiers in the system - thx Nicolai Hess for the request Make sure #null is resolved to ZnNullEncoder Add ZnCharacterEncoderTests>>#testKnownEncodingIdentifiers === Thanks again for the feedback, this is a useful addition. > On 6 Feb 2017, at 22:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 4 Feb 2017, at 13:01, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi Nicolai, > > > > The FileSystem API is a bit inconsistent, yes. > > > > This is how you can use it: > > > > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | > > out binary. > > (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. > > > > (FileLocator temp / 'foo.txt') readStreamDo: [ :in | > > in binary. > > ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | > > (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > There is no #binaryWriteStreamDo: > > > > The API around File is more correct, IMHO. > > > > Does this help ? > > > > Yes, thanks for the fast response. > > > > What exactly is your question ? > > > > I am looking at the issues with FileList, there are some parts that don't work anymore (see FileList>>#contents, it calls some unimplemted methods), and it uses TextConverter and somoe parts of the older File api. > > It looks like most other (newer) parts are using ZnCharacterReadstream for encoding, but I couldn't find a way to use it together with FileReferences (most parts of the FileList already operate with the newer FileSystem API. > > OK. > > From my standpoint and understanding, I would always use binary streams with explicit Zn converters, this combination is much easier to understand and better implemented with more features. > > If you encounter any problem or have any questions, I will gladly try to help you. > > :-) > Is there a way to list all supported encodings, similar to TextConverter class >> #allEncodingNames ? > I only found > ZnSimplifiedByteEncoder class >> #knownEncodingIdentifiers > and > ZnByteEncoder class >> #knownEncodingIdentifiers > and nothing for all supported utf-8/16 ... encodings. > > nicolai > > > > Sven > > > > > On 4 Feb 2017, at 12:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > Hi > > > How can I specify the character encoding when opening a readStream on a FileRerefence. > > > > > > I found this, that works: > > > > > > | readStream fileContent | > > > readStream := (File named: aFileName) openForRead. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > But if I try to do the same with a readStream from a FileReference > > > > > > | readStream fileContent | > > > readStream := aFileName asFileReference readStream. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > I get an error SmallInteger DNU #asciiValue, > > > > > > this is because, in the first method, we create a binary filestream, and if we > > > use readStream from a FileReference, the stream is a MultibyteFileStream. > > > > > > How can I us ZnEncoder for a readstream from a FileReference? > > > > > > (and is it on purpose that both readStream method (openForRead/readStream) > > > return different kinds of binary streams?) > > > > > > > > > nicolai

Feb. 7, 2017

Re: [Pharo-dev] Pharo 60 needs help on shortcuts-are-wrongly-displayed

by Pavel Krivanek

The uperchase character is the symbol on the key. In OS X the uppercase characters are used: http://cdn.osxdaily.com/wp-content/uploads/2011/07/access-library-lion.jpg In Chrome too: http://addoncrop.com/cdn/2014/12/Google-Chrome-Menu-Settions-option.png On Windows too: http://www.howtogeek.com/wp-content/uploads/2012/03/650x250xcontext-menu-sh… Cheers, -- Pavel 2017-02-06 17:57 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed > > The system should display Ctrl + s and not Ctrl + S > > Because people are pressing Shift to get S and this is not working. > We should distinguish between uppercase and lowercase. > The reader cannot guess that S is not the same as s + shift. > There is no way that a user can know that they should NOT press shift when > looking at Ctrl + S (because there is no noshiftPressed). > Ctrl + S means press Shift. >

Feb. 7, 2017

Re: [Pharo-dev] Debugger hang when step throught

by Denis Kudriashov

2017-02-07 10:30 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > More simple way to reproduce: > > #(2) select: [:i| i] > > > Problem somehow related to mustBeBoolean error. If you try debug > > #(2) select: [:i| i / 0] > > > Debugger will fallback into #/ method at ZeroDivide statement. But with > mustBeBoolean trick it's not work. > I open issue 19662 <https://pharo.fogbugz.com/f/cases/19662/Debugger-step-through-mustBeBoolean…> . Also I found another funny issue. Try debugIt following expression: 1 ifTrue: [2]. You will be wondering that debugger will not able to open.

Feb. 7, 2017

Re: [Pharo-dev] Debugger hang when step throught

by Denis Kudriashov

More simple way to reproduce: #(2) select: [:i| i] Problem somehow related to mustBeBoolean error. If you try debug #(2) select: [:i| i / 0] Debugger will fallback into #/ method at ZeroDivide statement. But with mustBeBoolean trick it's not work. 2017-02-07 8:03 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > tx for the report hilaire. > Indeed I can reproduce your bug > - I pasted it > - I did debug it > over over and through trhough and my system froze. > > On Mon, Feb 6, 2017 at 7:04 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> Hello, >> >> The faulty code bellow when debugged and 'step through' cause the >> debugger to hang: >> >> self inform: '1'. >> #(2 3 4) select: [:i| i] thenDo: [:n| self inform: n printString ]. >> self inform: '5'. >> >> It seems trapped in an infinite loop, you can more or less get control >> back with Alt+[.] >> >> >> When step in, the debugger properly report the error. >> >> Pharo #60362. >> >> >> I did not see similar bug report, shall I? >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

Feb. 7, 2017