- Pharo-dev - lists.pharo.org

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

[update 4.0] #40364

by Marcus Denker

40364 ----- 14422 AnnouncementSpy is not needed anymore: GTInspector has all the functionality https://pharo.fogbugz.com/f/cases/14422 14448 remove empty packages https://pharo.fogbugz.com/f/cases 14449 DNU #theme in Appearance setting https://pharo.fogbugz.com/f/cases/14449

Nov. 10, 2014

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

by stepharo

Marcus people are busy and we should let a chance to theme. What was the problem with theme in Settings. For example I was discussing with alain about the MouseOverHandler removal and it is not clear. Morphic and UI is complex so we should go slowly. 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 Marcus Denker

> 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

Who broke my System Preferences ?

by kilon alios

looks like latest Pharo 4 40363 broke System Preferences clicking on Appearance gives me this GraphicFontSettings class(Object)>>doesNotUnderstand: #theme GraphicFontSettings class>>fontSizeRow [ self fontSizeRow ] in GraphicFontSettings class>>standardFontsSettingsOn: in Block: [ self fontSizeRow ] PragmaSetting>>inputWidget PragmaSetting>>inputMorphFor: SettingNode>>inputMorphFor: [ :node :cont | node perform: self rowMorphGetSelector with: self container ] in MorphTreeColumn>>rowMorphGetterBlock in Block: [ :node :cont | node perform: self rowMorphGetSele...etc... MorphTreeColumn>>rowMorphFor: [ :col | | v | v := col rowMorphFor: complexContents. controls add: v. col -> v ] in MorphTreeNodeMorph>>buildRowMorph in Block: [ :col | ... OrderedCollection>>collect: MorphTreeNodeMorph>>buildRowMorph MorphTreeNodeMorph>>initRow MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: [ :item | priorMorph := self indentingItemClass new initWithContents: item prior: priorMorph forList: self indentLevel: parentMorph indentLevel + 1. morphList add: priorMorph. "Was this row expanded ? if true -> expand it again " priorMorph isExpanded ifTrue: [ priorMorph isExpanded: true. priorMorph addChildrenForList: self addingTo: morphList withExpandedItems: #() ] ] in MorphTreeMorph>>addMorphsAfter:fromCollection: in Block: [ :item | ... OrderedCollection>>do: MorphTreeMorph>>addMorphsAfter:fromCollection: MorphTreeNodeMorph>>expand MorphTreeNodeMorph>>toggleExpandedState MorphTreeMorph>>toggleExpandedState:event: MorphTreeMorph>>mouseDown: MorphTreeMorph(Morph)>>handleMouseDown: MouseButtonEvent>>sentTo: MorphTreeMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>dispatchEvent:with: MorphTreeMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>dispatchEvent:with: StandardWindow(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchMouseDown:with:

Nov. 10, 2014

Let's talk about Themes

by kilon alios

So I had a brief discussion with a newcomer to Pharo at IRC #pharo. He basically wanted to change the background color of a window. Naturally I assumed that is easy enough to do , so I though that window color in Preferences -> Appearance -> Morphic would do that trick but alas it did not. I am using PharoDark Theme and I found out that windowColor is not used and instead backgroundColor does the trick. Then it hit me, it would be really nice if a theme manager existed to make it easy for people to modify a theme at a basic level. "Damn it where is my Theme manager ? " which of course leads to the answer "Why you dont make one yourself?". So I decided to make one myself. I am not a fan of the idea to do this inside System Preferences because they are already too convoluted . So I am considering doing this as a separate tool as part of my Ephestos project. It is one the goals of my project to offer easy to create custom GUIs and of course a Theme manager is a first basic step. Now a first plan I had is to just create a single theme, that subclasses Dark Theme that I call Morpheas Theme and use that theme as a basis for every subtheme. So a theme will no longer be a class but rather a dictionary entry to an instance variable inside Morpheas Theme. The manager will basically allow to modify this dictionary with each sub theme having each own entry to this dictionary. I will try avoid messing with the code of other projects inside Pharo, ideally totally, it seems already the Dark Theme class can accomplish all I need. This approach ensures that structure of the theme remains the same only the data changes , keeping it clean and simple, with no need for the user to dive inside the code as it happens currently. So I am posting here since you guys are more experienced on this for your own opinion and though since I will do this at my own pace, slowly and step by step. I would like to avoid the pitfalls of unexperienced Pharo coder like me and of course make it easy also for other people to contribute.

Nov. 10, 2014

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

by Esteban Lorenzano

My own thoughts around this persistent stupid idea (and Iâm talking about the world, not a particular community: we suffer of the same time to time) is: no genius can match a community. Esteban > On 10 Nov 2014, at 12:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 10 Nov 2014, at 11:59, phil(a)highoctane.be wrote: >> >> I'd say that we have all have suffered enough from a sucky text editor. >> >> So, let's jump over the chasm with no regrets. >> >> We aren't doing Squeak, right? >> > > I Squeak, there was always some simple next step. But the community always said: > âNo, Genius person X is working on Y which will be oh-so-much-betterâ. > > And therefore, the next step was not done. Of course, Genius Person never finshed > Y, because, after nearly doing it, he realised: Wow, one can do it even better! > > And thus nothing was ever done. > > Marcus

Nov. 10, 2014