[Pharo-project] A question about UIManager
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
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 <stephane.ducasse@inria.fr> 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
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 <stephane.ducasse@inria.fr> 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
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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr> 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
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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr> 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
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
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
participants (2)
-
Fernando Olivero -
Stéphane Ducasse