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

[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

[Update] #40363

by Marcus Denker

14429 DebuggerTests package should be Debugger-Tests https://pharo.fogbugz.com/f/cases/14429 14431 FontInfrastructureTests package should be FontInfrastructure-Tests https://pharo.fogbugz.com/f/cases/14431 14430 EmbeddedFreeTypeTests package should be EmbeddedFreeType-Tests https://pharo.fogbugz.com/f/cases/14430

Nov. 10, 2014

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

by Marcus Denker

> 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

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

by phil＠highoctane.be

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? Phil On Mon, Nov 10, 2014 at 11:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I completely support that. > > We used Rubric in GT because we wanted to get the tools ready for Pharo > 3.0 and for early feedback in Pharo 4.0. Rubric is just a nice makeup of > the old TextMorph and it allows for finer grained programmatic support, but > it is clearly not the future. > > We have to focus on TxText. We are now in an Innovator's Dilemma > situation: TxText does not have all the bells and whistles that Rubric has, > but its foundation is dramatically better (objects all the way down, > screaming performance, vector graphics). We have to judge TxText by its > potential, not by its current state. Igor et co. has done a fantastic job, > and we have to embrace this and support their effort. > > Cheers, > Doru > > > > On Mon, Nov 10, 2014 at 11:17 AM, 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 >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 10, 2014

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

by Tudor Girba

I completely support that. We used Rubric in GT because we wanted to get the tools ready for Pharo 3.0 and for early feedback in Pharo 4.0. Rubric is just a nice makeup of the old TextMorph and it allows for finer grained programmatic support, but it is clearly not the future. We have to focus on TxText. We are now in an Innovator's Dilemma situation: TxText does not have all the bells and whistles that Rubric has, but its foundation is dramatically better (objects all the way down, screaming performance, vector graphics). We have to judge TxText by its potential, not by its current state. Igor et co. has done a fantastic job, and we have to embrace this and support their effort. Cheers, Doru On Mon, Nov 10, 2014 at 11:17 AM, 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 >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 10, 2014