Hello pharoers,

the last two days we worked hard with Marcus to incorporate this new
stuff into image, and now we're done.
All images past #13021 now have non interactive ui manager
(NonInteractiveUIManager).
We fixed almost all broken tests caused by introducing it (there are
only few minor ones left).
Probably there could be more infrastructure around that in future
(like redirecting Transcript output to some file/stdout while running
headless), but first things first.

Couple of words, what new stuff gives to you:

�- suppose you want to run image headless. Suppose that you probably
run an arbirary (or not so) piece of code,
which not always clear how well it goes.. and it could lead to
unwanted popups, like asking user to confirm something,
or even opening a debugger window, actually anything which leads to
one unwanted effect: making your image to wait for user's input or
other form of intervention,
which is completely what you don't wanna see on server image, because
it should run fully automated.

How it works:

UIManager, during image startup, checks if image runs headless, and if
so, then it switching to non-interactive mode.
The non-interactive mode means that any request to UI manager which
normally leads to some user interaction now will trigger an error
(ErrorNonInteractive).
If you run image headful again, it will switch to usual UI manager
back, so don't expect to have this error when running headful image.
And be careful when testing/writing your code: image will run using
different ui manager depending on startup conditions.

(Note: some VMs on some platforms filtering out the VM command line
parameters and image can't detect that it runs headless. To prevent
that, add extra -headless arg as last one in argument list.

For example:

� squeak -headless myImage.image myscript.st -headless

).

To test if image running headless, a new protocol was introduced:

Smalltalk isHeadless
and
Smallalk isInteractive

(which are antonyms).


Error handling:

In case if there an unhandled error occurs, the default behavior is:
�- print stack trace on log
�- quit image �( or save a new version of image and then quit) �- this
is controlled by preference, found in 'settings->Headless mode' group.

So, sometimes to track the error, you can turn this preference on,
then you can open saved instance of image and check with UI & debugger
what causing the error.
This is what you want to avoid to be default behavior on server,
because on server you need 24/7 service available without your
intervention :)
So, the normal setup for background images now will be to fire a fresh
image if current one dies ( and send mail with pharodebug.log contents
to root :) )

P.S. I hope these changes will make life for setting up headless
workflow much easier, because now we can easily track down all issues
which you can't see.
Because before that by default you having a hanging image, which doing
something or not (and you have no idea, because it headless).

P.P.S. For squeakers, if you want to harvest the changes, take the
changesets from here:

http://code.google.com/p/pharo/issues/detail?id=3593
http://code.google.com/p/pharo/issues/detail?id=3596

--
Best regards,
Igor Stasenko AKA sig.