Changing display depth

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing display depth

Frank Shearar-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Changing display depth

Jeff Gonis-2
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. So having Graphics be lower level than TBK makes sense when I come at it from that angle.

Thanks for your great work,
Jeff


Reply | Threaded
Open this post in threaded view
|

Re: Changing display depth

Hannes Hirzel
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.
 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Changing display depth

timrowledge
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