The Trunk: ToolBuilder-Kernel-dtl.34.mcz
Locked
 
|
David T. Lewis uploaded a new version of ToolBuilder-Kernel to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Kernel-dtl.34.mcz ==================== Summary ==================== Name: ToolBuilder-Kernel-dtl.34 Author: dtl Time: 2 May 2010, 6:15:49.448 pm UUID: d9bb885a-17d0-45ae-b93e-04cdf4e05a9f Ancestors: ToolBuilder-Kernel-MAD.33 Associate an instance of UIManager with each project, such that UIManager current refers to an appropriate instance for that type of project. Remove incomplete implementation of caching the current UIManager instance in class UIManager. Update class comment for UIManager. =============== Diff against ToolBuilder-Kernel-MAD.33 =============== Item was changed: ----- Method: UIManager class>>default (in category 'class initialization') ----- default + ^ Project current uiManager! - | mgrClass | - ^Default ifNil:[ - "Note: The way the following is phrased ensures that you can always make 'more specific' managers merely by subclassing a tool builder and implementing a more specific way of reacting to #isActiveManager. For example, a BobsUIManager can subclass MorphicUIManager and (if enabled, say Preferences useBobsUI) will be considered before the parent (generic MorphicUIManager)." - mgrClass := self allSubclasses - detect:[:any| any isActiveManager and:[ - any subclasses noneSatisfy:[:sub| sub isActiveManager]]] ifNone:[nil]. - mgrClass ifNotNil:[mgrClass new] - ].! Item was changed: Object subclass: #UIManager instanceVariableNames: '' + classVariableNames: '' - classVariableNames: 'Default' poolDictionaries: '' category: 'ToolBuilder-Kernel'! + !UIManager commentStamp: 'dtl 5/2/2010 16:06' prior: 0! + UIManager is a dispatcher for various user interface requests, such as menu and dialog interactions. An instance of UIManager is associated with each Project to implement the appropriate functions for Morphic, MVC or other user interfaces.! - !UIManager commentStamp: 'ar 12/27/2004 08:39' prior: 0! - UIManager is a dispatcher for various UI requests.! Item was added: + ----- Method: UIManager class>>getDefault (in category 'class initialization') ----- + getDefault + "Ensure that a more specific manager can always be made by subclassing + a tool builder and implementing a more specific way of reacting to + #isActiveManager. For example, a BobsUIManager can subclass + MorphicUIManager and (if enabled, say Preferences useBobsUI) will + be considered before the parent (generic MorphicUIManager)." + + ^ (self allSubclasses + detect: [:any | any isActiveManager + and: [any subclasses + noneSatisfy: [:sub | sub isActiveManager]]] + ifNone: []) + ifNotNilDo: [:mgrClass | mgrClass new]! Item was removed: - ----- Method: UIManager class>>default: (in category 'class initialization') ----- - default: aUIManager - Default := aUIManager! |
Re: The Trunk: ToolBuilder-Kernel-dtl.34.mcz
|
|
Since UIManager does not have any state, will this matter? YAGNI?
On Sun, May 2, 2010 at 5:19 PM, <[hidden email]> wrote: > David T. Lewis uploaded a new version of ToolBuilder-Kernel to project The Trunk: > http://source.squeak.org/trunk/ToolBuilder-Kernel-dtl.34.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Kernel-dtl.34 > Author: dtl > Time: 2 May 2010, 6:15:49.448 pm > UUID: d9bb885a-17d0-45ae-b93e-04cdf4e05a9f > Ancestors: ToolBuilder-Kernel-MAD.33 > > Associate an instance of UIManager with each project, such that UIManager current refers to an appropriate instance for that type of project. Remove incomplete implementation of caching the current UIManager instance in class UIManager. > > Update class comment for UIManager. > > =============== Diff against ToolBuilder-Kernel-MAD.33 =============== > > Item was changed: > ----- Method: UIManager class>>default (in category 'class initialization') ----- > default > + ^ Project current uiManager! > - | mgrClass | > - ^Default ifNil:[ > - "Note: The way the following is phrased ensures that you can always make 'more specific' managers merely by subclassing a tool builder and implementing a more specific way of reacting to #isActiveManager. For example, a BobsUIManager can subclass MorphicUIManager and (if enabled, say Preferences useBobsUI) will be considered before the parent (generic MorphicUIManager)." > - mgrClass := self allSubclasses > - detect:[:any| any isActiveManager and:[ > - any subclasses noneSatisfy:[:sub| sub isActiveManager]]] ifNone:[nil]. > - mgrClass ifNotNil:[mgrClass new] > - ].! > > Item was changed: > Object subclass: #UIManager > instanceVariableNames: '' > + classVariableNames: '' > - classVariableNames: 'Default' > poolDictionaries: '' > category: 'ToolBuilder-Kernel'! > > + !UIManager commentStamp: 'dtl 5/2/2010 16:06' prior: 0! > + UIManager is a dispatcher for various user interface requests, such as menu and dialog interactions. An instance of UIManager is associated with each Project to implement the appropriate functions for Morphic, MVC or other user interfaces.! > - !UIManager commentStamp: 'ar 12/27/2004 08:39' prior: 0! > - UIManager is a dispatcher for various UI requests.! > > Item was added: > + ----- Method: UIManager class>>getDefault (in category 'class initialization') ----- > + getDefault > + "Ensure that a more specific manager can always be made by subclassing > + a tool builder and implementing a more specific way of reacting to > + #isActiveManager. For example, a BobsUIManager can subclass > + MorphicUIManager and (if enabled, say Preferences useBobsUI) will > + be considered before the parent (generic MorphicUIManager)." > + > + ^ (self allSubclasses > + detect: [:any | any isActiveManager > + and: [any subclasses > + noneSatisfy: [:sub | sub isActiveManager]]] > + ifNone: []) > + ifNotNilDo: [:mgrClass | mgrClass new]! > > Item was removed: > - ----- Method: UIManager class>>default: (in category 'class initialization') ----- > - default: aUIManager > - Default := aUIManager! > > > |
Re: The Trunk: ToolBuilder-Kernel-dtl.34.mcz
|
|
I did not actually measure it, so I'm not sure if it matters with respect
to performance. That said, the method that figures out what flavor of UIManager to instantiate is a bit complex, so it may have some value. But the real reason I did it is that the UIManager was clearly designed with the intent of maintaining a reference to single instance while any given user interface is in effect. This was supported by referring to the default UIManager through a class variable. I presume the intent was to update this variable whenever the type of user interface changed (i.e. enter a different kind of project), although this had not yet been implemented in our trunk image. That approach made good sense when maintaining UIManager as a separate package, but it did require that the default UIManager be updated when changing projects, which actually ends up being a bit complicated (and that may be why it never got implemented). But the UIManager is conceptually related to Project, in the sense that a project has a kind of user interface, and the UIManager implements the appropriate UI requests for that kind of project. So it turns out to be simpler to just give the Project a UIManager, and not bother with trying to keep the value of "UIManager default" up to date when switching projects. And last but not least, it made the class comment simpler ;-) Dave On Mon, May 03, 2010 at 10:24:52AM -0500, Chris Muller wrote: > Since UIManager does not have any state, will this matter? YAGNI? > > On Sun, May 2, 2010 at 5:19 PM, <[hidden email]> wrote: > > David T. Lewis uploaded a new version of ToolBuilder-Kernel to project The Trunk: > > http://source.squeak.org/trunk/ToolBuilder-Kernel-dtl.34.mcz > > > > ==================== Summary ==================== > > > > Name: ToolBuilder-Kernel-dtl.34 > > Author: dtl > > Time: 2 May 2010, 6:15:49.448 pm > > UUID: d9bb885a-17d0-45ae-b93e-04cdf4e05a9f > > Ancestors: ToolBuilder-Kernel-MAD.33 > > > > Associate an instance of UIManager with each project, such that UIManager current refers to an appropriate instance for that type of project. Remove incomplete implementation of caching the current UIManager instance in class UIManager. > > > > Update class comment for UIManager. > > > > =============== Diff against ToolBuilder-Kernel-MAD.33 =============== |
Re: The Trunk: ToolBuilder-Kernel-dtl.34.mcz
|
|
On 5/3/2010 5:27 PM, David T. Lewis wrote:
> I did not actually measure it, so I'm not sure if it matters with respect > to performance. That said, the method that figures out what flavor of > UIManager to instantiate is a bit complex, so it may have some value. Not really. When you're about to ask the user for input you must include the user response times so you're not going to rely on calling any of the methods 1000/sec :-) > But the real reason I did it is that the UIManager was clearly designed > with the intent of maintaining a reference to single instance while any > given user interface is in effect. This was supported by referring to > the default UIManager through a class variable. I presume the intent > was to update this variable whenever the type of user interface changed > (i.e. enter a different kind of project), although this had not yet been > implemented in our trunk image. > > That approach made good sense when maintaining UIManager as a separate > package, but it did require that the default UIManager be updated > when changing projects, which actually ends up being a bit complicated > (and that may be why it never got implemented). But the UIManager > is conceptually related to Project, in the sense that a project has > a kind of user interface, and the UIManager implements the appropriate > UI requests for that kind of project. So it turns out to be simpler to > just give the Project a UIManager, and not bother with trying to keep > the value of "UIManager default" up to date when switching projects. Indeed. Your reasoning on the historical aspects is correct. I was trying to avoid external dependencies as much as possible. I actually still think that's somewhat worthwhile since it matters so little performance-wise. But I don't feel strongly about it. Cheers, - Andreas > And last but not least, it made the class comment simpler ;-) > > Dave > > On Mon, May 03, 2010 at 10:24:52AM -0500, Chris Muller wrote: >> Since UIManager does not have any state, will this matter? YAGNI? >> >> On Sun, May 2, 2010 at 5:19 PM,<[hidden email]> wrote: >>> David T. Lewis uploaded a new version of ToolBuilder-Kernel to project The Trunk: >>> http://source.squeak.org/trunk/ToolBuilder-Kernel-dtl.34.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: ToolBuilder-Kernel-dtl.34 >>> Author: dtl >>> Time: 2 May 2010, 6:15:49.448 pm >>> UUID: d9bb885a-17d0-45ae-b93e-04cdf4e05a9f >>> Ancestors: ToolBuilder-Kernel-MAD.33 >>> >>> Associate an instance of UIManager with each project, such that UIManager current refers to an appropriate instance for that type of project. Remove incomplete implementation of caching the current UIManager instance in class UIManager. >>> >>> Update class comment for UIManager. >>> >>> =============== Diff against ToolBuilder-Kernel-MAD.33 =============== > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |