- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Oct. 1, 2014

[pharo-project/pharo-core] 11e333: 40273

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 11e333080d87e57dd8d889e4088b73ad3b1440bd https://github.com/pharo-project/pharo-core/commit/11e333080d87e57dd8d889e4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-01 (Wed, 01 Oct 2014) Changed paths: A ConfigurationOfGTInspector.package/ConfigurationOfGTInspector.class/instance/versions/version101_.st A ConfigurationOfGTInspector.package/ConfigurationOfGTInspector.class/instance/versions/version102_.st A ConfigurationOfGTPlayground.package/ConfigurationOfGTPlayground.class/instance/versions/version101_.st A ConfigurationOfGTPlayground.package/ConfigurationOfGTPlayground.class/instance/versions/version102_.st A ConfigurationOfGlamour.package/ConfigurationOfGlamour.class/instance/versions/version271_.st A GT-InspectorExtensions-Core.package/extension/CollectionValueHolder/instance/announcer.st M GT-InspectorExtensions-Core.package/extension/Dictionary/instance/gtInspectorItemsIn_.st R GT-InspectorExtensions-Core.package/extension/GLMSystemWindow/instance/gtInspectorOpenTreeIn_.st M GT-InspectorExtensions-Core.package/extension/String/instance/gtInspectorTextIn_.st M GT-Playground.package/GTPlayground.class/instance/accessing/acceptContents_.st M GT-Playground.package/GTPlaygroundPage.class/instance/compatibility-tools/acceptContents_.st M Glamour-Morphic-Renderer.package/GLMMorphicPharoPlaygroundRenderer.class/instance/as yet unclassified/workspaceBindingsStrategy.st M Glamour-Morphic-Renderer.package/GLMMorphicSmalltalkCodeRenderer.class/instance/private/workspaceBindingsStrategy.st M Glamour-Morphic-Widgets.package/GLMPrintPopper.class/instance/initialization/initializeInspectButton.st M Glamour-Morphic-Widgets.package/GLMPrintPopper.class/instance/initialization/initializeTextMorph.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script273.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40273.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40273 14123 removed backgroundColor, fixed playgroundpage>>contents https://pharo.fogbugz.com/f/cases/14123 http://files.pharo.org/image/40/40273.zip

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Marcus Denker

On 01 Oct 2014, at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I think this is the wrong thing to do. We should reimplement the method in the UIManager. > Yes! > Doru > > On Wed, Oct 1, 2014 at 10:30 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > There is an acceptsContents: on GLMSystemWindow that delegates to the model, which in this case is the playground. > > On Wed, Oct 1, 2014 at 10:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > How did you fix it? > > Doru > > On Wed, Oct 1, 2014 at 10:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > I fixed for now the part with acceptsContents: > This should work when the issue is integrated > > UIManager default > edit: 'jlklkjk' > label: 'lkjlkjjkl'. > > On Wed, Oct 1, 2014 at 9:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Exactly. > > I created an entry for this: > https://pharo.fogbugz.com/f/cases/14133/UIManager-should-not-overuse-the-wo… > > Cheers, > Doru > > > On Wed, Oct 1, 2014 at 9:20 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 30 Sep 2014, at 20:41, stepharo <stepharo(a)free.fr> wrote: > > > edit: aText label: labelString accept: anAction > > "Open an editor on the given string/text" > > > > ^(Smalltalk tools workspace openLabel: labelString) > > acceptContents: aText; > > acceptAction: anAction; > > yourself. > > > > > > > Yes, we are abusing the workspace for an editor, this is not good. > > We should have an editor that is an editor, not a workspace. > > > -> DNU > > > > UIManager default > > edit: 'jlklkjk' > > label: 'lkjlkjjkl' > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Tudor Girba

I think this is the wrong thing to do. We should reimplement the method in the UIManager. Doru On Wed, Oct 1, 2014 at 10:30 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > There is an acceptsContents: on GLMSystemWindow that delegates to the > model, which in this case is the playground. > > On Wed, Oct 1, 2014 at 10:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> How did you fix it? >> >> Doru >> >> On Wed, Oct 1, 2014 at 10:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >>> I fixed for now the part with acceptsContents: >>> This should work when the issue is integrated >>> >>> UIManager default >>> edit: 'jlklkjk' >>> label: 'lkjlkjjkl'. >>> >>> On Wed, Oct 1, 2014 at 9:50 AM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Exactly. >>>> >>>> I created an entry for this: >>>> >>>> https://pharo.fogbugz.com/f/cases/14133/UIManager-should-not-overuse-the-wo… >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Wed, Oct 1, 2014 at 9:20 AM, Marcus Denker <marcus.denker(a)inria.fr> >>>> wrote: >>>> >>>>> >>>>> On 30 Sep 2014, at 20:41, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> > edit: aText label: labelString accept: anAction >>>>> > "Open an editor on the given string/text" >>>>> > >>>>> > ^(Smalltalk tools workspace openLabel: labelString) >>>>> > acceptContents: aText; >>>>> > acceptAction: anAction; >>>>> > yourself. >>>>> > >>>>> > >>>>> >>>>> >>>>> Yes, we are abusing the workspace for an editor, this is not good. >>>>> >>>>> We should have an editor that is an editor, not a workspace. >>>>> >>>>> > -> DNU >>>>> > >>>>> > UIManager default >>>>> > edit: 'jlklkjk' >>>>> > label: 'lkjlkjjkl' >>>>> > >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Andrei Chis

There is an acceptsContents: on GLMSystemWindow that delegates to the model, which in this case is the playground. On Wed, Oct 1, 2014 at 10:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > How did you fix it? > > Doru > > On Wed, Oct 1, 2014 at 10:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> I fixed for now the part with acceptsContents: >> This should work when the issue is integrated >> >> UIManager default >> edit: 'jlklkjk' >> label: 'lkjlkjjkl'. >> >> On Wed, Oct 1, 2014 at 9:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Exactly. >>> >>> I created an entry for this: >>> >>> https://pharo.fogbugz.com/f/cases/14133/UIManager-should-not-overuse-the-wo… >>> >>> Cheers, >>> Doru >>> >>> >>> On Wed, Oct 1, 2014 at 9:20 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>> >>>> >>>> On 30 Sep 2014, at 20:41, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> > edit: aText label: labelString accept: anAction >>>> > "Open an editor on the given string/text" >>>> > >>>> > ^(Smalltalk tools workspace openLabel: labelString) >>>> > acceptContents: aText; >>>> > acceptAction: anAction; >>>> > yourself. >>>> > >>>> > >>>> >>>> >>>> Yes, we are abusing the workspace for an editor, this is not good. >>>> >>>> We should have an editor that is an editor, not a workspace. >>>> >>>> > -> DNU >>>> > >>>> > UIManager default >>>> > edit: 'jlklkjk' >>>> > label: 'lkjlkjjkl' >>>> > >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Tudor Girba

How did you fix it? Doru On Wed, Oct 1, 2014 at 10:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > I fixed for now the part with acceptsContents: > This should work when the issue is integrated > > UIManager default > edit: 'jlklkjk' > label: 'lkjlkjjkl'. > > On Wed, Oct 1, 2014 at 9:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Exactly. >> >> I created an entry for this: >> >> https://pharo.fogbugz.com/f/cases/14133/UIManager-should-not-overuse-the-wo… >> >> Cheers, >> Doru >> >> >> On Wed, Oct 1, 2014 at 9:20 AM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>> >>> On 30 Sep 2014, at 20:41, stepharo <stepharo(a)free.fr> wrote: >>> >>> > edit: aText label: labelString accept: anAction >>> > "Open an editor on the given string/text" >>> > >>> > ^(Smalltalk tools workspace openLabel: labelString) >>> > acceptContents: aText; >>> > acceptAction: anAction; >>> > yourself. >>> > >>> > >>> >>> >>> Yes, we are abusing the workspace for an editor, this is not good. >>> >>> We should have an editor that is an editor, not a workspace. >>> >>> > -> DNU >>> > >>> > UIManager default >>> > edit: 'jlklkjk' >>> > label: 'lkjlkjjkl' >>> > >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Andrei Chis

I fixed for now the part with acceptsContents: This should work when the issue is integrated UIManager default edit: 'jlklkjk' label: 'lkjlkjjkl'. On Wed, Oct 1, 2014 at 9:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Exactly. > > I created an entry for this: > > https://pharo.fogbugz.com/f/cases/14133/UIManager-should-not-overuse-the-wo… > > Cheers, > Doru > > > On Wed, Oct 1, 2014 at 9:20 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> On 30 Sep 2014, at 20:41, stepharo <stepharo(a)free.fr> wrote: >> >> > edit: aText label: labelString accept: anAction >> > "Open an editor on the given string/text" >> > >> > ^(Smalltalk tools workspace openLabel: labelString) >> > acceptContents: aText; >> > acceptAction: anAction; >> > yourself. >> > >> > >> >> >> Yes, we are abusing the workspace for an editor, this is not good. >> >> We should have an editor that is an editor, not a workspace. >> >> > -> DNU >> > >> > UIManager default >> > edit: 'jlklkjk' >> > label: 'lkjlkjjkl' >> > >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 1, 2014

Re: [Pharo-dev] GTTools bug - why I cannot select the text by simply clicking at the end of it....

by Tudor Girba

It is tripple click :). If you click first to set the cursor, you still have to click three times to select the whole line. The nice thing though is that even if the cursor is not there, you still only require triple click to select the whole line. It's actually quite nice, but we would need the triple-click event in Pharo for that. Cheers, Doru On Wed, Oct 1, 2014 at 9:55 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I guess it should be double click on cursor because first click places the > cursor. When you open TextEdit with some text and do 3 consecutive clicks. > After the second click it selects the word your cursor is on, after 3rd one > it selects line that your cursor is on. I donât know, maybe other people > donât need this, but Iâm used to work with test like that, so maybe others > are too. > > Uko > > > On 01 Oct 2014, at 09:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Uko, > > I think you mean that triple clicking on the cursor when it is inside the > line should select the line, right? > > Cheers, > Doru > > > > On Wed, Oct 1, 2014 at 8:54 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> If my 2 cents make sense, it will be nice to have things similar to text >> editors. E.g. triple click for line select. >> >> Uko >> >> On 01 Oct 2014, at 07:51, stepharo <stepharo(a)free.fr> wrote: >> >> >> My perception is that this kind of small changes adds no value. >>> It just removes a small bit of value. >>> So it's going to frustrate someone for nothing. >>> Not a big frustration, I concede, but a gratuitous one. >>> >> >> I think its the opposite. People will simply adapt. >> >> >> Seriously I find that attitude really sad. >> So why don't add TxText with average syntax higthlitghting and that igor >> just does something else >> on the sake that people will adapt. >> >> For me there is no justification for not having the same behavior with is >> working perfectly well. >> It is not a question of dogma but just pragmatic >> - it works well >> - it is handy >> - it is not incompatible with the double click dogma. >> >> >> Finally, the best thing it brings is exposing that some events are >>> handled incorrectly. >>> At least I hope it will give us a chance to correct them :) >>> >> >> :) >> >> Doru >> >> >> >>> >>> 2014-09-30 22:59 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>>> Hi, >>>> >>>> I can see how people get use with this behavior, but I am quite >>>> certain that the solution from PluggableTextMorph was a workaround solution >>>> due to a missing double click event. Now we have that event and we can use >>>> it where it is appropriate. >>>> >>>> It's not that we copy things for the sake of copying, but I simply >>>> think double clicking is a better choice here. click-pause-click >>>> introduces, from a cognitive perspective, a hidden modal mode. That is, you >>>> have no chance of knowing in which state you are. I was several times >>>> annoyed by inadvertently selecting pieces of code (often during demos). At >>>> the same time, I believe it is reasonable to assume that programmers know >>>> how to double click. >>>> >>>> So, yes, I did think of it quite explicitly :) >>>> >>>> Doub >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Tue, Sep 30, 2014 at 10:46 PM, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>>> I find click pause click useful. >>>>> No stress nor necessary adjustment of double-click delay. >>>>> What could be the intention of a user clicking repeatedly on the same >>>>> area? >>>>> Did you think of it? >>>>> If copying what everyone else does is the sole value, then let's not >>>>> do Pharo. >>>>> >>>>> 2014-09-30 21:34 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>> >>>>>> Hi, >>>>>> >>>>>> I explained before but it went unnoticed. The selection happens on >>>>>> double click like in any other editor. >>>>>> >>>>>> The regular PluggableTextMorph also tries to do it on a kind of a >>>>>> double click, only it is implemented as click-pause-click. So, if you click >>>>>> once, wait 5 minutes, and click again, it will select. This is not >>>>>> particularly useful. >>>>>> >>>>>> So, Rubric selects on double click. >>>>>> >>>>>> Now, as I mentioned before, there happens to be a random double >>>>>> click issue. I cannot reproduce it, but sometimes it happens. Also, when I >>>>>> save the image and load it back, the problem is gone. Please note that this >>>>>> issue is not related to Rubric, but to the double click event throughout >>>>>> the entire image. For example, if you see that double click does not work >>>>>> in Rubric, try to double click on the window title to maximize a window and >>>>>> you will see that it does not work. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Sep 30, 2014 at 8:42 PM, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>>> With the previous tools I can select a piece of text by clicking >>>>>>> after its last element and now I cannot >>>>>>> or I can but sometimes. >>>>>>> >>>>>>> So what is the fix? >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTTools bug - why I cannot select the text by simply clicking at the end of it....

by Yuriy Tymchuk

I guess it should be double click on cursor because first click places the cursor. When you open TextEdit with some text and do 3 consecutive clicks. After the second click it selects the word your cursor is on, after 3rd one it selects line that your cursor is on. I donât know, maybe other people donât need this, but Iâm used to work with test like that, so maybe others are too. Uko > On 01 Oct 2014, at 09:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Uko, > > I think you mean that triple clicking on the cursor when it is inside the line should select the line, right? > > Cheers, > Doru > > > > On Wed, Oct 1, 2014 at 8:54 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > If my 2 cents make sense, it will be nice to have things similar to text editors. E.g. triple click for line select. > > Uko > >> On 01 Oct 2014, at 07:51, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> >>> My perception is that this kind of small changes adds no value. >>> It just removes a small bit of value. >>> So it's going to frustrate someone for nothing. >>> Not a big frustration, I concede, but a gratuitous one. >>> >>> I think its the opposite. People will simply adapt. >> >> Seriously I find that attitude really sad. >> So why don't add TxText with average syntax higthlitghting and that igor just does something else >> on the sake that people will adapt. >> >> For me there is no justification for not having the same behavior with is working perfectly well. >> It is not a question of dogma but just pragmatic >> - it works well >> - it is handy >> - it is not incompatible with the double click dogma. >> >>> >>> Finally, the best thing it brings is exposing that some events are handled incorrectly. >>> At least I hope it will give us a chance to correct them :) >>> >>> :) >>> >>> Doru >>> >>> >>> >>> 2014-09-30 22:59 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >>> Hi, >>> >>> I can see how people get use with this behavior, but I am quite certain that the solution from PluggableTextMorph was a workaround solution due to a missing double click event. Now we have that event and we can use it where it is appropriate. >>> >>> It's not that we copy things for the sake of copying, but I simply think double clicking is a better choice here. click-pause-click introduces, from a cognitive perspective, a hidden modal mode. That is, you have no chance of knowing in which state you are. I was several times annoyed by inadvertently selecting pieces of code (often during demos). At the same time, I believe it is reasonable to assume that programmers know how to double click. >>> >>> So, yes, I did think of it quite explicitly :) >>> >>> Doub >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Sep 30, 2014 at 10:46 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >>> I find click pause click useful. >>> No stress nor necessary adjustment of double-click delay. >>> What could be the intention of a user clicking repeatedly on the same area? >>> Did you think of it? >>> If copying what everyone else does is the sole value, then let's not do Pharo. >>> >>> 2014-09-30 21:34 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >>> Hi, >>> >>> I explained before but it went unnoticed. The selection happens on double click like in any other editor. >>> >>> The regular PluggableTextMorph also tries to do it on a kind of a double click, only it is implemented as click-pause-click. So, if you click once, wait 5 minutes, and click again, it will select. This is not particularly useful. >>> >>> So, Rubric selects on double click. >>> >>> Now, as I mentioned before, there happens to be a random double click issue. I cannot reproduce it, but sometimes it happens. Also, when I save the image and load it back, the problem is gone. Please note that this issue is not related to Rubric, but to the double click event throughout the entire image. For example, if you see that double click does not work in Rubric, try to double click on the window title to maximize a window and you will see that it does not work. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Sep 30, 2014 at 8:42 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> With the previous tools I can select a piece of text by clicking after its last element and now I cannot >>> or I can but sometimes. >>> >>> So what is the fix? >>> >>> Stef >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Tudor Girba

Exactly. I created an entry for this: https://pharo.fogbugz.com/f/cases/14133/UIManager-should-not-overuse-the-wo… Cheers, Doru On Wed, Oct 1, 2014 at 9:20 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 30 Sep 2014, at 20:41, stepharo <stepharo(a)free.fr> wrote: > > > edit: aText label: labelString accept: anAction > > "Open an editor on the given string/text" > > > > ^(Smalltalk tools workspace openLabel: labelString) > > acceptContents: aText; > > acceptAction: anAction; > > yourself. > > > > > > > Yes, we are abusing the workspace for an editor, this is not good. > > We should have an editor that is an editor, not a workspace. > > > -> DNU > > > > UIManager default > > edit: 'jlklkjk' > > label: 'lkjlkjjkl' > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014