November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cmd+click in Rubric

by kilon alios

The reason why I dont contribute to Pharo and decided to create my own project because frankly I cannot risk my code get rejected or debated upon. I know I am new to Pharo and I am not experienced coder in any way but still my free time is super valuable to me. I had made one contribution to Pharo and it met some fierce resistance and I had zero problem with that. My fix was accepted. I know people have their own preferences and ideologies when it comes to coding like all things in life and I think its 100% to reject my code or request an improvement. Frankly I am also afraid of braking things and making other people life miserably. But rejections and debates cost me valuable time. Sure if i was paid I would have zero problem. I mention this because I hear again and again, why people do not contribute. This is my reason. On Mon, Nov 10, 2014 at 5:36 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I didnât tell anything about Alain investing into Rubric. Itâs just that > Rubric is in GTInspector which I use, and I miss cmd+click feature. I think > I could help to work on txText, but Iâve already broken quite a lot of > things in Smalllint, so Iâll continue improving that part :) > > Uko > > > > On 10 Nov 2014, at 11:17, stepharo <stepharo(a)free.fr> wrote: > > > > Guys > > > > I just discussed with Alain who is at my place working with Igor. > > Alain will not invest in Rubric. Rubric is the past. I told him to send > a mail but he told me that he already said it. > > We should push txText. I will spend some time with igor to push it again > but we need more people to have a look > > and help. > > > > Stef > > > > On 9/11/14 18:12, Yuriy Tymchuk wrote: > >> Dear all. > >> > >> Iâve already reported this issue but didnât make it clear. > >> > >> When I cmd+click some text in nautilus, I can âbrowseâ it. This means > browse class implementation, browse method implementors. When I cmd+click > something in rubric it opens a context menu. > >> > >> I anybody using cmd+click besides of me? > >> Can this be solved? > >> > >> Uko > >> > > > > > > >

Nov. 10, 2014

Re: [Pharo-dev] Let's talk about Themes

by kilon alios

Actually my point was the creation of themes, thats what a theme manager does. No its not easy, its not easy to have to go to the System Browser find Dark Theme class, try to guess which method is responsible for the background color and then go the usual Pharo rabbit hole of senders and implementors so that I dont brake anything. It kills my inner child. Slowly. Painfully. Plus if it was that easy we would be overwhelmed by Themes right now . A year has passed since the Dark Theme appeared and all I hear is crickets and frogs. I have not seen anyone announce a theme as third party either. Also my experience with it for an hour I spent on it rates "extremely hard". About moving away from static values and replace them with references I agree 100% with you but you also mention the very important that its something we have to agree on and I dont want to go through the pain of asking permission each time I want to do something like that. My goals is not to improve Theme support , its more to leverage the power of Dark Theme and make it easy for people, I mean really easy, to create their own themes without having to write a line code. Because writing code to create a theme , makes no sense to me whatsoever. Nothing spectacular just a simple, easy to use, fun theme manager. I just started the thread so people can share their wisdom on the subject, maybe even make request that I may find cool enough to implement. On Mon, Nov 10, 2014 at 5:08 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > The point is not the creation of a theme. That is easy. And editing is too. > The problem is that you need to check the whole system and get rid of > all the constants and replace them by references to symbolic values in > the application theme. There is the value. > > For example > CheckBoxExample>>defaultSpec > > ^ { #ContainerModel. > #add:. { self topSpec. #layout:. > #(#SpecLayoutFrame > > bottomFraction: 0 > > bottomOffset: 20) }. > #add:. {{#model . #container } . #layout: . > #(#SpecLayoutFrame topOffset: 22) } > } > > the values 20 and 22 need to be replaced. They are dependent on at least > the font size. > > There are lots of these, e.g. > CredentialEditor class >>defaultSpec > <sepc: #default> > > ^ SpecLayout composed > newColumn: [ :col | > col > newRow: [ :r | r add: #usernameLabel > width: 80; add: #username ] height: self inputTextHeight; > newRow: [ :r | r add: #passwordLabel > width: 80; add: #password ] height: self inputTextHeight + 4; > newRow: [ :r | r add: #showPasswordWidget > width: 120; newColumn: [ :c | ] ] height: self inputTextHeight + 4; > newRow: [ :r | ] > ]; > yourself > > That <sepc: #default> looks like a typo btw. > > These values are often composites, something like > textSize+2*textLineVerticalSeparation. > Coming up with good symbolic names is not trivial either. > > Stephan >

Nov. 10, 2014

Re: [Pharo-dev] Cmd+click in Rubric

by Yuriy Tymchuk

I didnât tell anything about Alain investing into Rubric. Itâs just that Rubric is in GTInspector which I use, and I miss cmd+click feature. I think I could help to work on txText, but Iâve already broken quite a lot of things in Smalllint, so Iâll continue improving that part :) Uko > On 10 Nov 2014, at 11:17, stepharo <stepharo(a)free.fr> wrote: > > Guys > > I just discussed with Alain who is at my place working with Igor. > Alain will not invest in Rubric. Rubric is the past. I told him to send a mail but he told me that he already said it. > We should push txText. I will spend some time with igor to push it again but we need more people to have a look > and help. > > Stef > > On 9/11/14 18:12, Yuriy Tymchuk wrote: >> Dear all. >> >> Iâve already reported this issue but didnât make it clear. >> >> When I cmd+click some text in nautilus, I can âbrowseâ it. This means browse class implementation, browse method implementors. When I cmd+click something in rubric it opens a context menu. >> >> I anybody using cmd+click besides of me? >> Can this be solved? >> >> Uko >> > >

Nov. 10, 2014

Re: [Pharo-dev] What changed in compiler/RB that causes Seaside tests failures?

by Johan Brichau

> On 10 Nov 2014, at 15:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 10 Nov 2014, at 15:51, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> The slime tests that run in Pharo 3 fail in 4. And there are significant differences between >> running the tests in-image and in ci. >> >> https://ci.inria.fr/pharo-contribution/job/Pharo4Seaside/ >> > > This could be side effects of the changes in the CodeCriticsâ¦ Yes, and for Grease these were fixed just last Saturday [1] I assume the fixes for Slime Seaside will be the same. Johan [1] https://ci.inria.fr/pharo-contribution/job/Grease/419/ <https://ci.inria.fr/pharo-contribution/job/Grease/419/>

Nov. 10, 2014

Re: [Pharo-dev] Let's talk about Themes

by Stephan Eggermont

The point is not the creation of a theme. That is easy. And editing is too. The problem is that you need to check the whole system and get rid of all the constants and replace them by references to symbolic values in the application theme. There is the value. For example CheckBoxExample>>defaultSpec ^ { #ContainerModel. #add:. { self topSpec. #layout:. #(#SpecLayoutFrame bottomFraction: 0 bottomOffset: 20) }. #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) } } the values 20 and 22 need to be replaced. They are dependent on at least the font size. There are lots of these, e.g. CredentialEditor class >>defaultSpec <sepc: #default> ^ SpecLayout composed newColumn: [ :col | col newRow: [ :r | r add: #usernameLabel width: 80; add: #username ] height: self inputTextHeight; newRow: [ :r | r add: #passwordLabel width: 80; add: #password ] height: self inputTextHeight + 4; newRow: [ :r | r add: #showPasswordWidget width: 120; newColumn: [ :c | ] ] height: self inputTextHeight + 4; newRow: [ :r | ] ]; yourself That <sepc: #default> looks like a typo btw. These values are often composites, something like textSize+2*textLineVerticalSeparation. Coming up with good symbolic names is not trivial either. Stephan

Nov. 10, 2014

Re: [Pharo-dev] Who broke my System Preferences ?

by kilon alios

no worries I would not even dream to blame you and yes I completely agree that you did not need to wait for a review ,after all its not that much of a big deal to ping the mailing list as I did and you fixing it at your own pace , I can always use an older build at any time. The Theme classes is kinda strange, I think that Pharo needs a standard on theme support and that standard must be deeply rooted inside Morphic so that each morph implements its own theme support. Of course for that the community will need to sit down and agree what that standard must be or else you will see theme classes popping around like mushrooms. On Mon, Nov 10, 2014 at 3:46 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 10 Nov 2014, at 14:18, kilon alios <kilon.alios(a)gmail.com> wrote: > > > > looks like latest Pharo 4 40363 broke System Preferences clicking on > Appearance gives me this > > > > Oh, I missed call in fontSizeRowâ¦ I thought I tested it. I will fix it... > (Hint: I always wait for people to review my changesâ¦ but that does not > happen very often) > > > Marcus >

Nov. 10, 2014

Re: [Pharo-dev] What changed in compiler/RB that causes Seaside tests failures?

by Marcus Denker

> On 10 Nov 2014, at 15:51, Stephan Eggermont <stephan(a)stack.nl> wrote: > > The slime tests that run in Pharo 3 fail in 4. And there are significant differences between > running the tests in-image and in ci. > > https://ci.inria.fr/pharo-contribution/job/Pharo4Seaside/ > This could be side effects of the changes in the CodeCriticsâ¦ Marcus

Nov. 10, 2014

What changed in compiler/RB that causes Seaside tests failures?

by Stephan Eggermont

The slime tests that run in Pharo 3 fail in 4. And there are significant differences between running the tests in-image and in ci. https://ci.inria.fr/pharo-contribution/job/Pharo4Seaside/ Stephan

Nov. 10, 2014

Re: [Pharo-dev] Who broke my System Preferences ?

by Marcus Denker

> On 10 Nov 2014, at 15:45, stepharo <stepharo(a)free.fr> wrote: > > I do not understand? > did you change self theme by the Smalltalk ui theme in the class? > I do not see why this is an improvement. > yeaâ¦ I wanted to normally move the whole class somewhere else, but then I stopped and just committed what I had. I did the #theme thing because it looks so ugly to have #theme implemented everywhere (we have 33 implementors! 33!!) and I just saw two senders in this classâ¦ All the Theme stuff is so uglyâ¦ > May be changing > theme > UIManager default theme > > by > theme > ^ Smalltalk ui theme > > is better but not expanding all the self theme with this expression > Because we do not know in the future how the theme will be implemented in the future. > > Stef > > > On 10/11/14 14:46, Marcus Denker wrote: >>> On 10 Nov 2014, at 14:18, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> looks like latest Pharo 4 40363 broke System Preferences clicking on Appearance gives me this >>> >> Oh, I missed call in fontSizeRowâ¦ I thought I tested it. I will fix it... >> (Hint: I always wait for people to review my changesâ¦ but that does not happen very often) >> >> >> Marcus >> >> > >

Nov. 10, 2014

Re: [Pharo-dev] Who broke my System Preferences ?

by stepharo

I do not understand? did you change self theme by the Smalltalk ui theme in the class? I do not see why this is an improvement. May be changing theme UIManager default theme by theme ^ Smalltalk ui theme is better but not expanding all the self theme with this expression Because we do not know in the future how the theme will be implemented in the future. Stef On 10/11/14 14:46, Marcus Denker wrote: >> On 10 Nov 2014, at 14:18, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> looks like latest Pharo 4 40363 broke System Preferences clicking on Appearance gives me this >> > Oh, I missed call in fontSizeRowâ¦ I thought I tested it. I will fix it... > (Hint: I always wait for people to review my changesâ¦ but that does not happen very often) > > > Marcus > >

Nov. 10, 2014