So once again I find myself catching up with Pavel's work.
He said a while back that:
DisplayScreen>>newDepthNoRestore: - delegation to UIManager, MorphicUIManager implementation should be added
What I think that means is this: * moving DisplayScreen >> #newDepth: to UIManager >> #newDepth: * changing "Display newDepth: foo" to "UIManager default newDepth: foo" * adding UIManager >> newDepthNoRestore: as a self subclassResponsibility * changing any "Display newDepthNoRestore: foo" occurrences * moving DisplayScreen >> #newDepthNoRestore to MorphicUIManager >> #newDepthNoRestore: * copying most of MorphicUIManager >> #newDepthNoRestore: to MVCUIManager or whatever it's called ("most" means "everything outside a Smalltalk isMorphic ifTrue: []")
This * delegates setting screen depth to the UIManager, and * avoids making Graphics depend on ToolBuilder-Kernel (because TBK already depends on Graphics (because of a probably removable test case thing))
The assumption here is that Graphics is lower level/more fundamental than TBK.
Thoughts?
frank
On Wed, Oct 30, 2013 at 4:56 PM, Frank Shearar frank.shearar@gmail.comwrote:
So once again I find myself catching up with Pavel's work.
He said a while back that:
DisplayScreen>>newDepthNoRestore:
- delegation to UIManager, MorphicUIManager implementation should be added
What I think that means is this:
- moving DisplayScreen >> #newDepth: to UIManager >> #newDepth:
- changing "Display newDepth: foo" to "UIManager default newDepth: foo"
- adding UIManager >> newDepthNoRestore: as a self subclassResponsibility
- changing any "Display newDepthNoRestore: foo" occurrences
- moving DisplayScreen >> #newDepthNoRestore to MorphicUIManager >>
#newDepthNoRestore:
- copying most of MorphicUIManager >> #newDepthNoRestore: to
MVCUIManager or whatever it's called ("most" means "everything outside a Smalltalk isMorphic ifTrue: []")
This
- delegates setting screen depth to the UIManager, and
- avoids making Graphics depend on ToolBuilder-Kernel (because TBK
already depends on Graphics (because of a probably removable test case thing))
The assumption here is that Graphics is lower level/more fundamental than TBK.
Thoughts?
frank
Hi Frank,
This assumption seems eminently reasonable to me. Smalltalk has long been focused on providing a direct graphical representation of the system to the user. This says to me then that, before we can make tools for the system, we need a way of representing them onscreen. So having Graphics be lower level than TBK makes sense when I come at it from that angle.
Thanks for your great work, Jeff
On 10/30/13, Jeff Gonis jeff.gonis@gmail.com wrote:
On Wed, Oct 30, 2013 at 4:56 PM, Frank Shearar frank.shearar@gmail.comwrote:
So once again I find myself catching up with Pavel's work.
He said a while back that:
DisplayScreen>>newDepthNoRestore:
- delegation to UIManager, MorphicUIManager implementation should be
added
What I think that means is this:
- moving DisplayScreen >> #newDepth: to UIManager >> #newDepth:
- changing "Display newDepth: foo" to "UIManager default newDepth: foo"
- adding UIManager >> newDepthNoRestore: as a self subclassResponsibility
- changing any "Display newDepthNoRestore: foo" occurrences
- moving DisplayScreen >> #newDepthNoRestore to MorphicUIManager >>
#newDepthNoRestore:
- copying most of MorphicUIManager >> #newDepthNoRestore: to
MVCUIManager or whatever it's called ("most" means "everything outside a Smalltalk isMorphic ifTrue: []")
This
- delegates setting screen depth to the UIManager, and
- avoids making Graphics depend on ToolBuilder-Kernel (because TBK
already depends on Graphics (because of a probably removable test case thing))
The assumption here is that Graphics is lower level/more fundamental than TBK.
Thoughts?
frank
Hi Frank,
This assumption seems eminently reasonable to me. Smalltalk has long been focused on providing a direct graphical representation of the system to the user. This says to me then that, before we can make tools for the system, we need a way of representing them onscreen.
So having Graphics be lower
level than TBK makes sense when I come at it from that angle.
+1
Thanks for your great work,
Jeff
On 30-10-2013, at 3:56 PM, Frank Shearar frank.shearar@gmail.com wrote:
So once again I find myself catching up with Pavel's work.
{snip}
The assumption here is that Graphics is lower level/more fundamental than TBK.
Sounds sensible to me. a tool builder either depends upon having Graphics with which to build the tool, or some other mechanism that is independent of Graphics (say, ExternalHostGraphicsForWayland).
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Dukedom: aristocratic birth control
squeak-dev@lists.squeakfoundation.org