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