The Trunk: ToolBuilder-Kernel-dtl.42.mcz

David T. Lewis uploaded a new version of ToolBuilder-Kernel to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Kernel-dtl.42.mcz

==================== Summary ====================

Name: ToolBuilder-Kernel-dtl.42
Author: dtl
Time: 5 March 2011, 9:57:05.186 am
UUID: eb80fd84-c1a5-463c-b95d-66096ec8eb63
Ancestors: ToolBuilder-Kernel-dtl.41

Change Toolbuilder class>>default to always ask the default UI manager for its tool builder. Remove class var Default (this was provided in the ToolBuilder package but never used in Squeak). Deprecate ToolBuilder class>>default:

Background: In previous Squeak usage, ToolBuilder class>>default always invoked a search for the appropriate ToolBuilder subclass, and class var Default was unused (this is awkward if more than one kind of ToolBuilder could be used in a project that #isMorphic). This change makes the default tool builder an explicit attibute of the active UI manager.

=============== Diff against ToolBuilder-Kernel-dtl.41 ===============

Item was changed:
  Object subclass: #ToolBuilder
  instanceVariableNames: 'parent'
+ classVariableNames: ''
- classVariableNames: 'Default'
  poolDictionaries: ''
  category: 'ToolBuilder-Kernel'!
 
  !ToolBuilder commentStamp: '<historical>' prior: 0!
  I am a tool builder, that is an object which knows how to create concrete widgets from abstract specifications. Those specifications are used by tools which want to be able to function in diverse user interface paradigms, such as MVC, Morphic, Tweak, wxWidgets etc.
 
  The following five specs must be supported by all implementations:
  * PluggableButton
  * PluggableList
  * PluggableText
  * PluggablePanel
  * PluggableWindow
 
  The following specs are optional:
  * PluggableTree: If not supported, the tool builder must answer nil when asked for a pluggableTreeSpec. Substitution will require client support so clients must be aware that some tool builders may not support trees (MVC for example, or Seaside). See examples in FileListPlus or TestRunnerPlus.
  * PluggableMultiSelectionList: If multi-selection lists are not supported, tool builder will silently support regular single selection lists.
  * PluggableInputField: Intended as a HINT for the builder that this widget will be used as a single line input field. Unless explicitly supported it will be automatically substituted by PluggableText.
  * PluggableActionButton: Intended as a HINT for the builder that this widget will be used as push (action) button. Unless explicitly supported it will be automatically substituted by PluggableButton.
  * PluggableRadioButton: Intended as a HINT for the builder that this widget will be used as radio button. Unless explicitly supported it will be automatically substituted by PluggableButton.
  * PluggableCheckBox: Intended as a HINT for the builder that this widget will be used as check box. Unless explicitly supported it will be automatically substituted by PluggableButton.
  !

Item was changed:
  ----- Method: ToolBuilder class>>default (in category 'accessing') -----
  default
  "Answer the default tool builder"
+ ^ Project current uiManager toolBuilder
+ ifNil: [self findDefault]!
- ^Default ifNil: [Default := self findDefault]!

Item was changed:
  ----- Method: ToolBuilder class>>default: (in category 'accessing') -----
  default: aToolBuilder
  "Set a new default tool builder"
+ self deprecated: 'The default ToolBuilder is an attribute of the UIManager'
+ !
- Default := aToolBuilder.!

I really should apologize, as these ToolBuilder changes should have been
vetted through the inbox. If anyone thinks this is a bad idea, I'll revert
them. I have to admit that the 'Project current uiManager toolBuilder'
construct is a bit awkward (though better I think than searching for
a ToolBuilder subclass on every reference).

Dave


On Sat, Mar 05, 2011 at 02:57:08PM +0000, [hidden email] wrote: