[Pharo-project] About NonInteractiveUIManager>>#onSnapshot: and related

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Mar 21 02:51:40 EDT 2012


we should add that to the class comment.
and method comment.
can somebody open a ticket?

Stef

On Mar 21, 2012, at 5:07 AM, Igor Stasenko wrote:

> the logic there was to set a non-interactive ui manager
> for headless sessions only , and then restore back a previous one
> (whatever it is), once session is changed back to headfull.
> 
> if its uiManager is nil, it should reset the default manager,
> if i remember correctly, then UImanager itself will take care
> instantiating default one.
> 
> On 21 March 2012 04:35, Guillermo Polito <guillermopolito at gmail.com> wrote:
>> Hi,
>> 
>> I was doing some hacking, and playing with NonInteractiveUIManager.  And it
>> puzzled me that I realized that it has an inst var uiManager that seems to
>> refer to an uiManager it's replacing.
>> But my UIManager is not replacing anyone, it's my default and unique
>> UIManager and this var points to nil :S!
>> 
>> So the code below does not work...
>> 
>> onSnapshot: resuming
>>     "The resuming argument is true when image boots from disk,
>>     and false, if user just did an image snapshot."
>> 
>>     resuming ifTrue: [
>>         Smalltalk isHeadless ifFalse: [
>>             "restore old, or nil, so it will be set in #default "
>>                 uiManager beDefault.
>>                 UIManager default onSnapshot: resuming.
>>             ^ self ].
>>         Smalltalk isInteractive ifTrue: [
>>             "use a headless but interactive manager"
>>             ^ self headlessManager onSnapshot: resuming ]].
>> 
>> 
>>     " this flag set to true only if we are saving a snapshot before quitting
>> "
>>     doNotQuitOnRestart ifTrue: [
>>         Smalltalk snapshot: false andQuit: true].
>> 
>> 
>> I made it work in my image adding within the controversial lines:
>> 
>> uiManager ifNotNil: [
>>     uiManager beDefault.
>>     UIManager default onSnapshot: resuming.
>> ]
>> 
>> But it really looks like a hack because that inst var is ment to do
>> something else...
>> Is it asking me for a refactor?  Or am I using this stuff in the wrong way?
>> Camillo, Igor? :P
>> 
>> Guille
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.
> 





More information about the Pharo-dev mailing list