Headless UI manager - set active how?

I think the bug I'm seeing in my build process is caused by that modal
"No changes" dialog our update stream currently throws up.

To test this, I've written a near-stub HeadlessUIManager. A UIManager
indicates that it may be used by returning true from #isActiveManager.

I have two questions:

(a) How can I detect whether or not I'm running headless, from within the image?

(b) Given that MorphicUIManager class >> #isActiveManager returns true
if there's a World, and I'm not quite ready to set World to nil
because running headless is relatively unsupported, how do I make sure
that _this_ UIManager runs, and not _that_ one?

I'd expected a UIManager class >> #default: like ToolSet has. Or even
better, something based on a resumable exception.

Thanks!

frank

Hi Frank,

> To test this, I've written a near-stub HeadlessUIManager. A UIManager
> indicates that it may be used by returning true from #isActiveManager.
>
> I have two questions:
>
> (a) How can I detect whether or not I'm running headless, from within the image?

I use the method in that CommandLine handler package I sent to you a
while back.  It simply checks command-line args:

SmalltalkImage>>#isHeadless
     "Display global is set even when headless.  So checking the -vm
arguments looking for headless operation."
     -1000
          to: -1
          do:
               [ : n |
               (#('display=none' '-headless' '-vm-display-null')
includes: (self getSystemAttribute: n)) ifTrue: [ ^ true ] ].
     ^ false

> (b) Given that MorphicUIManager class >> #isActiveManager returns true
> if there's a World, and I'm not quite ready to set World to nil
> because running headless is relatively unsupported, how do I make sure
> that _this_ UIManager runs, and not _that_ one?

How about just handling ProvideAnswerNotification from a high level?

     [nil inform: 'No changes']
          on: ProvideAnswerNotification
          do: [ : noti | noti defaultAction ]

You might want even more error handling than that, though, for running
headless.  Check out that CommandLineProcessor in the Ma-Core package.
   I've been using it for several years now for running batch in
headless or headful operation.  All the error handling for printing
messages and stack traces and exiting the image vs. halting, etc. is
handled fairly elegantly by this one class.

> I'd expected a UIManager class >> #default: like ToolSet has. Or even
> better, something based on a resumable exception.

ProvideAnswerNotification.

On 8 August 2013 00:07, Chris Muller <[hidden email]> wrote:
(a) Sorry for not reading the code you sent me. (b) I'd really hoped
to avoid reading the arguments supplied to the VM, precisely because
of the variance in the parameter. But if that's what I need to do,
that's what I need to do...

Yes, I could do that too, and it's a cheaper way to validate my
hypothesis. Thanks!

>> I'd expected a UIManager class >> #default: like ToolSet has. Or even
>> better, something based on a resumable exception.
>
> ProvideAnswerNotification.

Well, no. That's how you communicate with the UIManager, for sure.
What I want is for the "UIManager default" part to be configurable. If
it used a resumable exception I could even test
ProvideAnswerNotification's behaviour. At the moment, if I try write
such a test, I can't control which UIManager is used.

But I'm wary of just slapping resumable exceptions all over the place.
The cost to find out the resumed value is linear in the call stack,
and it's a serious pain to debug code that uses delimited dynamic
variables. Unless you don't care about the lookup, of course. But if
the lookup's what you're debugging...

frank