A question about UIManager
Locked
 
|
Hi pharoers
I was trying to change MenuMorph direct reference to use UIManager because I was thinking that a popup menu should not open alone but this is the responsibility of the UIManager and I was not happy. why because we have these UIManager default and I started to think about them (ok I'm dead nearly sleeping at 9 in the evening because I took too much sun and walk today). My gut feeling is that at least for UI code, any UI element could have an access to the current UIManager via an instance variable or a message. self uiManager. Now may be the UI World should point to the UIMAnager and each graphical element should access it like that. For non UI class then this is a different story. But I would like to get your point of view on that point. Tx stef |
Re: A question about UIManager
|
|
I believe that any UI element, should answer uiManager. And hardcoding
the class in a single uiManager method in Morph is a good idea. So i vote in favor of Morph>>uiManager ^ MorphicUIManager default. Following the same line of thought we should do the same for the globals World, ActiveWorld, ActiveEvent and ActiveHand. I've provided with the code in Issue 3903: Removing the Globals World, ActiveHand and ActiveEvent. As well as direct references to WorldState. Fernando On Sun, Apr 10, 2011 at 9:21 PM, Stéphane Ducasse <[hidden email]> wrote: > Hi pharoers > > I was trying to change MenuMorph direct reference to use UIManager because I was thinking > that a popup menu should not open alone but this is the responsibility of the UIManager and I was not happy. > why because we have these > UIManager default > > and I started to think about them (ok I'm dead nearly sleeping at 9 in the evening because I took too much sun > and walk today). My gut feeling is that at least for UI code, any UI element could have an access to the current UIManager > via an instance variable or a message. > self uiManager. > Now may be the UI World should point to the UIMAnager and each graphical element should access it like that. > For non UI class then this is a different story. > > But I would like to get your point of view on that point. > > Tx > > stef > |
Re: A question about UIManager
|
|
thanks!
Stef On Apr 10, 2011, at 10:31 PM, Fernando Olivero wrote: > I believe that any UI element, should answer uiManager. And hardcoding > the class in a single uiManager method in Morph is a good idea. So i > vote in favor of Morph>>uiManager ^ MorphicUIManager default. > > Following the same line of thought we should do the same for the > globals World, ActiveWorld, ActiveEvent and ActiveHand. > I've provided with the code in Issue 3903: Removing the Globals > World, ActiveHand and ActiveEvent. As well as direct references to > WorldState. > > Fernando > > On Sun, Apr 10, 2011 at 9:21 PM, Stéphane Ducasse > <[hidden email]> wrote: >> Hi pharoers >> >> I was trying to change MenuMorph direct reference to use UIManager because I was thinking >> that a popup menu should not open alone but this is the responsibility of the UIManager and I was not happy. >> why because we have these >> UIManager default >> >> and I started to think about them (ok I'm dead nearly sleeping at 9 in the evening because I took too much sun >> and walk today). My gut feeling is that at least for UI code, any UI element could have an access to the current UIManager >> via an instance variable or a message. >> self uiManager. >> Now may be the UI World should point to the UIMAnager and each graphical element should access it like that. >> For non UI class then this is a different story. >> >> But I would like to get your point of view on that point. >> >> Tx >> >> stef >> > |
Re: A question about UIManager
|
|
Actually i havent uploaded the fix yet, so this is good because now i
can modify the changeset to adopt Morph>>uiManager. Stef, what do you think about the class vars of SystemWindow, should they also be moved to UIManager: for example TopWindow and associated protocol. In Issue 3917:Make all uses of SystemWindow go thru UIManger, i provided an initial implementation. I've replaced the refs of SystemWindow to UIManager>>newWindowLabelled: aString, and eliminated the class vars in favor of ivars of the MorphiUIManager. Fernando On Mon, Apr 11, 2011 at 7:37 AM, Stéphane Ducasse <[hidden email]> wrote: > thanks! > > Stef > > On Apr 10, 2011, at 10:31 PM, Fernando Olivero wrote: > >> I believe that any UI element, should answer uiManager. And hardcoding >> the class in a single uiManager method in Morph is a good idea. So i >> vote in favor of Morph>>uiManager ^ MorphicUIManager default. >> >> Following the same line of thought we should do the same for the >> globals World, ActiveWorld, ActiveEvent and ActiveHand. >> I've provided with the code in Issue 3903: Removing the Globals >> World, ActiveHand and ActiveEvent. As well as direct references to >> WorldState. >> >> Fernando >> >> On Sun, Apr 10, 2011 at 9:21 PM, Stéphane Ducasse >> <[hidden email]> wrote: >>> Hi pharoers >>> >>> I was trying to change MenuMorph direct reference to use UIManager because I was thinking >>> that a popup menu should not open alone but this is the responsibility of the UIManager and I was not happy. >>> why because we have these >>> UIManager default >>> >>> and I started to think about them (ok I'm dead nearly sleeping at 9 in the evening because I took too much sun >>> and walk today). My gut feeling is that at least for UI code, any UI element could have an access to the current UIManager >>> via an instance variable or a message. >>> self uiManager. >>> Now may be the UI World should point to the UIMAnager and each graphical element should access it like that. >>> For non UI class then this is a different story. >>> >>> But I would like to get your point of view on that point. >>> >>> Tx >>> >>> stef >>> >> > > |
Re: A question about UIManager
|
|
>>> the class in a single uiManager method in Morph is a good idea. So i
>>> vote in favor of Morph>>uiManager ^ MorphicUIManager default. But it should not be MorphicUIManager default. because else we cannot use the DummyUIManager. So it should be UIManager default. In general referencing to subclasses defeat the purpose of UIManager On Apr 11, 2011, at 8:57 AM, Fernando Olivero wrote: > Actually i havent uploaded the fix yet, so this is good because now i > can modify the changeset to adopt Morph>>uiManager. > > Stef, what do you think about the class vars of SystemWindow, should > they also be moved to UIManager: for example TopWindow and associated > protocol. I do not know. > In Issue 3917:Make all uses of SystemWindow go thru UIManger, i > provided an initial implementation. I've replaced the refs of > SystemWindow to UIManager>>newWindowLabelled: aString, yes it looks good. > and eliminated the class vars in favor of ivars of the MorphiUIManager. I do not know for this one. Sytef > > Fernando > > On Mon, Apr 11, 2011 at 7:37 AM, Stéphane Ducasse > <[hidden email]> wrote: >> thanks! >> >> Stef >> >> On Apr 10, 2011, at 10:31 PM, Fernando Olivero wrote: >> >>> I believe that any UI element, should answer uiManager. And hardcoding >>> the class in a single uiManager method in Morph is a good idea. So i >>> vote in favor of Morph>>uiManager ^ MorphicUIManager default. >>> >>> Following the same line of thought we should do the same for the >>> globals World, ActiveWorld, ActiveEvent and ActiveHand. >>> I've provided with the code in Issue 3903: Removing the Globals >>> World, ActiveHand and ActiveEvent. As well as direct references to >>> WorldState. >>> >>> Fernando >>> >>> On Sun, Apr 10, 2011 at 9:21 PM, Stéphane Ducasse >>> <[hidden email]> wrote: >>>> Hi pharoers >>>> >>>> I was trying to change MenuMorph direct reference to use UIManager because I was thinking >>>> that a popup menu should not open alone but this is the responsibility of the UIManager and I was not happy. >>>> why because we have these >>>> UIManager default >>>> >>>> and I started to think about them (ok I'm dead nearly sleeping at 9 in the evening because I took too much sun >>>> and walk today). My gut feeling is that at least for UI code, any UI element could have an access to the current UIManager >>>> via an instance variable or a message. >>>> self uiManager. >>>> Now may be the UI World should point to the UIMAnager and each graphical element should access it like that. >>>> For non UI class then this is a different story. >>>> >>>> But I would like to get your point of view on that point. >>>> >>>> Tx >>>> >>>> stef >>>> >>> >> >> > |
Re: A question about UIManager
|
|
In reply to this post by Stéphane Ducasse
I was reading code on UITheme current everywhere and I was thinking:
either we can add a method in Morph or we could add a trait for ThemeAndInteraction: uimanager, uitheme.... I think that using a trait would be good because we could have Morph that is the underlying layer and the tools and widgets that need to be theme managed using the trait. What do you think? There is already TEasyTheme but to me it looks too large. Stef |
Re: A question about UIManager
|
|
In reply to this post by Stéphane Ducasse
I found
theme "Answer the current theme for the receiver." (self valueOfProperty: #theme) ifNotNil: [:t | ^ t]. ^(self window ifNil: [self class]) theme in Morph theme: aUITheme "Set the current theme for the receiver." self theme = aUITheme ifFalse: [ self setProperty: #theme toValue: aUITheme. self themeChanged] and theme is defined on the Morph class so this means that we can change the UITheme current by self theme :) Stef |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |