May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about theme and friends

by stephane ducasse

On May 14, 2013, at 5:36 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Please do bear in mind having multiple themes concurrently in use. > Whilst we have a theme for the devolopment environment, instances of applications can have their own etc. Ok we will :) > > Regards, Gary > ----- Original Message ----- > From: Benjamin > To: Discusses Development of Pharo > Sent: Tuesday, May 14, 2013 4:22 PM > Subject: Re: [Pharo-dev] about theme and friends > > Ok, my bad :) > > This is a massive refactoring, but indeed, it may be cool :) > Ben > > On May 14, 2013, at 5:18 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> >> On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> The problem is the overlapping. >>> For settings, different project do not define the same settings. >>> >>> But for tools, it's different >>> By example, Browser, and Nautilus will try to register to default browser. >> >> I'm not talking about this level. >> No registration about tools. UITheme does not deal with that. >> >> The current theme should push to all the widgets that the defaultColor is blue. >> >> >> >>> >>> Ben >>> >>> On May 14, 2013, at 4:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> esteban >>>> >>>> I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the >>>> one of settings. >>>> >>>> Every widget should have custom hooks and setter, getter and default values. >>>> The hooks should be annotated or registered seomwhere. >>>> Then the widget code simply uses the hooks normally. >>>> >>>> Now a theme changes should push new values onto these hooks. >>>> >>>> This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. >>>> I will try to build a small experiment but I'm sure that this is the solution >>>> >>>> Nobody call settings nowadays (as it was the case with Preferences in the past). >>>> >>>> Stef

May 14, 2013

Re: [Pharo-dev] about theme and friends

by stephane ducasse

StandardWindow>>defaultColor "Answer the default color/fill style for the receiver" ^self theme windowColor to me I would put windowColor as a variable of the window. Stef On May 14, 2013, at 4:55 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > esteban > > I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the > one of settings. > > Every widget should have custom hooks and setter, getter and default values. > The hooks should be annotated or registered seomwhere. > Then the widget code simply uses the hooks normally. > > Now a theme changes should push new values onto these hooks. > > This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. > I will try to build a small experiment but I'm sure that this is the solution > > Nobody call settings nowadays (as it was the case with Preferences in the past). > > Stef

May 14, 2013

Re: [Pharo-dev] about theme and friends

by StÃ©phane Ducasse

On May 14, 2013, at 10:03 PM, Dennis Groves <dennis.groves(a)gmail.com> wrote: > How do I get off this list? I never subscribed - so I don't have a login. :( Ask nicely :) We never added you so someone should have done it. We will remove you. > > > -- > [Dennis Groves](http://about.me/dennis.groves), MSc > [Email me](mailto:dennis.groves@owasp.org) or [schedule a meeting](http://goo.gl/8sPIy). > >> "Unless someone like you...cares a whole awful lot...nothing is going to get better...It's not." -- The Lorax >

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Marcus Denker

On May 14, 2013, at 10:04 PM, "Dennis Groves" <dennis.groves(a)gmail.com> wrote: > How do I get off this list? I never subscribed - so I don't have a login. :( > I will remove you. But it's strange. I took all email addresses that where in the old pharo-project list and added them here. So the other list did send mails to your address beforeâ¦ maybe you filtered them? But I have seen stranger things with Mailman ;-). Marcus.

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Dennis Groves

How do I get off this list? I never subscribed - so I don't have a login. :( -- [Dennis Groves](http://about.me/dennis.groves), MSc [Email me](mailto:dennis.groves@owasp.org) or [schedule a meeting](http://goo.gl/8sPIy). > "Unless someone like you...cares a whole awful lot...nothing is going > to get better...It's not." -- The Lorax

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Tudor Girba

Hi, I was rather thinking of having the theme be a composable factory: - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory. - the UITheme simply stores all these factories, and the morph looks the factory up via the theme. - the UITheme will have no more subclasses. - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme. This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside. Cheers, Doru On May 14, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Looking at the code I have the impression that many UITheme methods should be moved to the their classes > > Example: > > > UITheme>>newGroupboxIn: aThemedMorph label: aString > "Answer a groupbox with the given label." > > ^GroupboxMorph new > font: self labelFont; > cornerStyle: aThemedMorph preferredCornerStyle; > hResizing: #spaceFill; > vResizing: #spaceFill; > label: aString; > yourself > > Why this is not a creation method on GroupBox? > > Then the trait TeasilyThemed looks suspicious to me. > > > -- www.tudorgirba.com "Presenting is storytelling."

May 14, 2013

vm fixes

by Esteban Lorenzano

Hi, I just pushed fix for a weird bug in cocoa cog vm. It was crashing image when resizing using DisplayScreen>>#hostWindowSize: but even worst, some times was crashing also when dragging a window outside the world screen... The fix is there, but you will need to wait until tomorrow to have it in zeroconf (because of weird mac jenkins slave permissions). This increases a bit more the VM stability, still not perfect, but we are getting closer :) Esteban

May 14, 2013

Re: [Pharo-dev] about theme and friends

by StÃ©phane Ducasse

Looking at the code I have the impression that many UITheme methods should be moved to the their classes Example: UITheme>>newGroupboxIn: aThemedMorph label: aString "Answer a groupbox with the given label." ^GroupboxMorph new font: self labelFont; cornerStyle: aThemedMorph preferredCornerStyle; hResizing: #spaceFill; vResizing: #spaceFill; label: aString; yourself Why this is not a creation method on GroupBox? Then the trait TeasilyThemed looks suspicious to me.

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Sven Van Caekenberghe

On 14 May 2013, at 17:35, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Something like > > self performIfExists: #blah > > would reduce the noise a lot :) > Then in this methods, we do what we want ^^ IMHO, lots of #respondsTo: or #isKindOf: are a sign of bad code, bad design. But in a number of key places a #performIfExists: can be very helpful and even necessary. Sven > Ben > > On May 14, 2013, at 5:32 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I'm in favor killing all the respondsTo: >>> >>> acceptTextMorphs >>> "Accept any text morphs except for those that have no edits." >>> >>> self allMorphs do: [:p | >>> ((p respondsTo: #accept) and: [ >>> (p respondsTo: #hasUnacceptedEdits) and: [ >>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> They're a step up from #isKindOf:. It looks like you need is something >> that says "does this object respond to a particular set of messages >> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >> :) ) >> >> But in this particular case the solution looks like making a >> #insertADecentNameHere that particular classes of things can implement >> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >> >> frank >> >

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Chris Muller

One of the most innovative concepts Smalltalk brought as a language in the 1970's is the notion of sending messages. I don't think removing #respondsTo: will help cure bad code. For a system as capable as Pharo, to go far with it, I just don't think there's any way around the need for students to /learn/ the best practices and not use unnecessary reflection in apps. But /app-building/ frameworks often need to be able to reflect on the code model. On Tue, May 14, 2013 at 10:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I'm in favor killing all the respondsTo: > > acceptTextMorphs > "Accept any text morphs except for those that have no edits." > > self allMorphs do: [:p | > ((p respondsTo: #accept) and: [ > (p respondsTo: #hasUnacceptedEdits) and: [ > p hasUnacceptedEdits]]) ifTrue: [p accept]] > > :) > > And there are too many Smalltalk references in the system >

May 14, 2013