- Pharo-dev - lists.pharo.org

is Kommiter working for you in 40 latest?

by stepharo

is Kommiter working for you in 40 latest? Because I get an error tellling to me that it cannot find Applications / Pharo?

Oct. 1, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Sven Van Caekenberghe

On 01 Oct 2014, at 06:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > On Tue, Sep 30, 2014 at 11:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Sep 2014, at 23:50, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Indeed, the same is true for some GT classes (I was looking at Glamour-Morphic-Pager-Morphic): no (a few) class comments, let alone method comments. > > Glamour is the engine, GT is the application of it for the IDE of Pharo. And yes, the Morphic binding of Glamour has few comments. This should be improved. The comments are important for us to be able to understand all this new stuff. > Being a default part of Pharo is an honour, it will push you further, but it comes with a big responsibility. > > I am not sure how to position this remark. It looks like you wanted to make us feel ashamed in some way. I think we showed that we do take it seriously. We are sorry if our effort is not be good enough, but we will continue working and asking other people to join. Haha, no shaming, of course. > This brings me to the second thing: I think you meant to say that it will push *us* further :). We need more people to put effort in this. Not for GT, but for Pharo. Sure it is a group thing from now on. But you have to understand: we just replaced two very important tools with something totally new, I now miss tons of stuff, and I want most of it back, in some way or another. On the other hand, I too see the potential and the new, additional features. I promise, I will make a list ;-) > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTInspector + Fuel

by Tudor Girba

Hi Mariano, I am not sure I understand the implication of using addPostMaterializationAction: in combination with the inspector materialization extension. Where do you see the opportunity? Cheers, Doru On Tue, Sep 30, 2014 at 10:52 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > That's very nice!!! > > > And that ... together with the ability to define > #addPostMaterializationAction: is a super awesome combination :) > > On Tue, Sep 30, 2014 at 5:17 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 30.09.2014, at 22:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> :) >> >> Doru >> >> >> On Tue, Sep 30, 2014 at 10:11 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>> Hi, >>> >>> sorry if this is a known thing, but Iâve just notices this and it made >>> my day. >>> >>> So in GTInspector you can browse filesystem, but when you select a fuel >>> file, you can press a "plusâ button in top right corner, and it >>> materialises the object. Amazing. >>> >> >> Hehe ;) Took me 10 minutes on MooseDay (including showing meta info) :D >> >> GT rocks! >> >> >>> Uko >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTTool bug:

by Tudor Girba

Hi, I think that acceptAction: should not be the responsibility of the playground and that we should implement this behavior with a different widget. Cheers, Doru On Tue, Sep 30, 2014 at 10:20 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > I think that there may be sense to create a trait or at least some doc > that will say which functionality should current tools implement. Because I > believe that it is hard to find out what is used by everyone. And as we > have another tools now and some unimplemented things it makes sense to > document it now, while we know what is missing. > > Uko > > > 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. > > > > > > -> DNU > > > > UIManager default > > edit: 'jlklkjk' > > label: 'lkjlkjjkl' > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Tudor Girba

On Tue, Sep 30, 2014 at 11:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Sep 2014, at 23:50, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Indeed, the same is true for some GT classes (I was looking at > Glamour-Morphic-Pager-Morphic): no (a few) class comments, let alone method > comments. Glamour is the engine, GT is the application of it for the IDE of Pharo. And yes, the Morphic binding of Glamour has few comments. This should be improved. Being a default part of Pharo is an honour, it will push you further, but > it comes with a big responsibility. > I am not sure how to position this remark. It looks like you wanted to make us feel ashamed in some way. I think we showed that we do take it seriously. We are sorry if our effort is not be good enough, but we will continue working and asking other people to join. This brings me to the second thing: I think you meant to say that it will push *us* further :). We need more people to put effort in this. Not for GT, but for Pharo. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Tudor Girba

Hi, On Tue, Sep 30, 2014 at 11:50 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Looking at all those red exclamation marks, it looks like > there is still much to do. > > Not documenting dozens of Announcement subclasses, ok, but > > RubTextComposer has many many instvars. > RubParagraph has nearly 100 methods > RubTextEditor has over 200 methods. > (These are only some examples of classes that look important). > This is a whole new Text/Editor/Model-Framework with up to no > documentation. > > The example widgets look great, and maybe Rubric is a good and easy to > learn > framework, but seriously, we should do better. > Thanks for the feedback. Yes, we will do better. Of course, people can join if they want to. Doru > 2014-09-30 14:51 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> â¦ that :) >> Which means that now we have a long way to polish them until Pharo4 >> release. >> >> Please test and provide feedback :) >> >> Esteban >> > > -- 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

Hi, On Wed, Oct 1, 2014 at 12:47 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > You're right, a modal UI that would involve a triple, quadruple click or > cycle between even more states would be annoying. > But just switching a selection, how so? Personnally I don't mind. Is it a > matter of taste? > Anyway, the whole text editor is modal, mind you, did you see this thing > named cursor? > If I pause, then start typing again, it writes where I stopped 5 minutes > ago instead of where my own focus shifted... That's quite stupid ;) > Or maybe you suggest the right solution would be a vanishing cursor > materializing the loss of focus of the text widget after an arbitrary > delay, for the sake of relaxing my cognitive load? > At the same time, the comparison is a bit stretched because we are talking about the problem of having one detached input device with one signal at a time. For this reason, it is precisely the invention of a cursor that ameliorates the problem. If the cursor would not be visible, you would indeed have a huge problem. But, the cursor being clearly visible makes the whole situation much less problematic. Modes are not good because I have to remember where I am. If I can avoid them, I do. > From the implementation point of view, handling click-pause-click is more > than simple by reusing the existing selection state and is not requiring > any arbitrary Delay and its additional states. > So I don't see a huge value in suppressing it. > Is it motivated by cleaning code duplication after adding a specific > double click handling? > Or is reducing the features to a core set a goal per se? > We did not suppress anything. Alain implemented it from scratch and instead of making it the responsibility of a text editor to manipulate fake-double-clicking, he used double clicking. 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. > 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"

Oct. 1, 2014

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

by Nicolas Cellier

You're right, a modal UI that would involve a triple, quadruple click or cycle between even more states would be annoying. But just switching a selection, how so? Personnally I don't mind. Is it a matter of taste? Anyway, the whole text editor is modal, mind you, did you see this thing named cursor? If I pause, then start typing again, it writes where I stopped 5 minutes ago instead of where my own focus shifted... That's quite stupid ;) Or maybe you suggest the right solution would be a vanishing cursor materializing the loss of focus of the text widget after an arbitrary delay, for the sake of relaxing my cognitive load? >From the implementation point of view, handling click-pause-click is more than simple by reusing the existing selection state and is not requiring any arbitrary Delay and its additional states. So I don't see a huge value in suppressing it. Is it motivated by cleaning code duplication after adding a specific double click handling? Or is reducing the features to a core set a goal per se? 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. 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 :) 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" >

Sept. 30, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Sven Van Caekenberghe

On 30 Sep 2014, at 23:50, Nicolai Hess <nicolaihess(a)web.de> wrote: > Looking at all those red exclamation marks, it looks like > there is still much to do. > > Not documenting dozens of Announcement subclasses, ok, but > > RubTextComposer has many many instvars. > RubParagraph has nearly 100 methods > RubTextEditor has over 200 methods. > (These are only some examples of classes that look important). > > This is a whole new Text/Editor/Model-Framework with up to no > documentation. > > The example widgets look great, and maybe Rubric is a good and easy to learn > framework, but seriously, we should do better. Indeed, the same is true for some GT classes (I was looking at Glamour-Morphic-Pager-Morphic): no (a few) class comments, let alone method comments. Being a default part of Pharo is an honour, it will push you further, but it comes with a big responsibility. > 2014-09-30 14:51 GMT+02: 0 Esteban Lorenzano <estebanlm(a)gmail.com>: > â¦ that :) > Which means that now we have a long way to polish them until Pharo4 release. > > Please test and provide feedback :) > > Esteban > > <PharoScreenshot.png>

Sept. 30, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Nicolai Hess

Looking at all those red exclamation marks, it looks like there is still much to do. Not documenting dozens of Announcement subclasses, ok, but RubTextComposer has many many instvars. RubParagraph has nearly 100 methods RubTextEditor has over 200 methods. (These are only some examples of classes that look important). This is a whole new Text/Editor/Model-Framework with up to no documentation. The example widgets look great, and maybe Rubric is a good and easy to learn framework, but seriously, we should do better. 2014-09-30 14:51 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > â¦ that :) > Which means that now we have a long way to polish them until Pharo4 > release. > > Please test and provide feedback :) > > Esteban >

Sept. 30, 2014