I thought to test things like Display extent & DisplayScreen actualScreenDepth but these either fall back to values in the pre-headless image or don't fail and answer the actual display depth, even though the VM is running headless (at least on Mac they do).
On 31 August 2011 18:28, Eliot Miranda eliot.miranda@gmail.com wrote:
I thought to test things like Display extent & DisplayScreen actualScreenDepth but these either fall back to values in the pre-headless image or don't fail and answer the actual display depth, even though the VM is running headless (at least on Mac they do).
ahaa! you seem to be facing same problems as we had :)
Nothing. I found no reliable way to detect that image are running headless, there is no VM api for exposing that. And this is sad.
The way how pharo images detecting it currently is to check a command-line arguments passed to VM. See SmalltalkImage isHeadless in pharo 1.3 - 1.4 images.
it is ugly, but i think this is better than detecting via Display, because its more direct.
We should fix that. either by adding a new primitive , or adding new system attribute..
But my personal preference is to let image control the headless mode, i.e. instead of making VM decide whether image should be forced to run headless or not, an image should check a command line, and then instruct VM to create a window or not. This IMO would be the best solution to the problem. VM should provide access to features and/or facilities, and image should decide whether use them or not.
Even if VM decides to not allow UI, then it should report to an image that given facility is not available, and play with it in nice manner, but not like today when image has no idea what happens and leaving it without any clues in what environment it running.
On Wed, 31 Aug 2011, Igor Stasenko wrote:
On 31 August 2011 18:28, Eliot Miranda eliot.miranda@gmail.com wrote:
I thought to test things like Display extent & DisplayScreen actualScreenDepth but these either fall back to values in the pre-headless image or don't fail and answer the actual display depth, even though the VM is running headless (at least on Mac they do).
ahaa! you seem to be facing same problems as we had :)
Nothing. I found no reliable way to detect that image are running headless, there is no VM api for exposing that. And this is sad.
The way how pharo images detecting it currently is to check a command-line arguments passed to VM. See SmalltalkImage isHeadless in pharo 1.3 - 1.4 images.
it is ugly, but i think this is better than detecting via Display, because its more direct.
We should fix that. either by adding a new primitive , or adding new system attribute..
But my personal preference is to let image control the headless mode, i.e. instead of making VM decide whether image should be forced to run headless or not, an image should check a command line, and then instruct VM to create a window or not.
Running "headless" has nothing to do with having windows or not. We're running our images with vm-display-none, but we're still use windows, because we connect to our images via RFB.
Since RFB also uses Display, therefore detecting headless mode with Display checks is not trivial.
Levente
This IMO would be the best solution to the problem. VM should provide access to features and/or facilities, and image should decide whether use them or not.
Even if VM decides to not allow UI, then it should report to an image that given facility is not available, and play with it in nice manner, but not like today when image has no idea what happens and leaving it without any clues in what environment it running.
-- Best regards, Igor Stasenko AKA sig.
On 1 September 2011 00:33, Levente Uzonyi leves@elte.hu wrote:
On Wed, 31 Aug 2011, Igor Stasenko wrote:
On 31 August 2011 18:28, Eliot Miranda eliot.miranda@gmail.com wrote:
I thought to test things like Display extent & DisplayScreen actualScreenDepth but these either fall back to values in the pre-headless image or don't fail and answer the actual display depth, even though the VM is running headless (at least on Mac they do).
ahaa! you seem to be facing same problems as we had :)
Nothing. I found no reliable way to detect that image are running headless, there is no VM api for exposing that. And this is sad.
The way how pharo images detecting it currently is to check a command-line arguments passed to VM. See SmalltalkImage isHeadless in pharo 1.3 - 1.4 images.
it is ugly, but i think this is better than detecting via Display, because its more direct.
We should fix that. either by adding a new primitive , or adding new system attribute..
But my personal preference is to let image control the headless mode, i.e. instead of making VM decide whether image should be forced to run headless or not, an image should check a command line, and then instruct VM to create a window or not.
Running "headless" has nothing to do with having windows or not. We're running our images with vm-display-none, but we're still use windows, because we connect to our images via RFB.
In my terminology, headless is image running without UI from OS side. What happens inside an image is another story.
Since RFB also uses Display, therefore detecting headless mode with Display checks is not trivial.
sure thing image can do whatever it wants. but it should be aware that there is no UI from OS side. that VM runs headless or call it whatever you want.
Levente
This IMO would be the best solution to the problem. VM should provide access to features and/or facilities, and image should decide whether use them or not.
Even if VM decides to not allow UI, then it should report to an image that given facility is not available, and play with it in nice manner, but not like today when image has no idea what happens and leaving it without any clues in what environment it running.
-- Best regards, Igor Stasenko AKA sig.
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Igor Stasenko -
Levente Uzonyi