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 <[hidden email]> wrote: So once again I find myself catching up with Pavel's work. 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 <[hidden email]> wrote:
> On Wed, Oct 30, 2013 at 4:56 PM, Frank Shearar > <[hidden email]>wrote: > >> 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. > level than TBK makes sense when I come at it from that angle. +1 > Thanks for your great work, > Jeff > |
In reply to this post by Frank Shearar-3
On 30-10-2013, at 3:56 PM, Frank Shearar <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Dukedom: aristocratic birth control |
Free forum by Nabble | Edit this page |