On 21 January 2011 11:04, Sven Van Caekenberghe <s...@beta9.be> wrote: > Igor, > > Headless support is an important feature. > It should be something simple so that it can be used in many ways. > I would suggest to read chapter 20 of the VW Application Developers Guide (it > is only 10 pages). > > They basically have the option to toggle between headless and headfull. > This is not detected automatically, but a global switch (with a test method). > > In headless mode all display access results in an error.
yes. > In headless mode all Transcript output (can/is) also sent to a file (stdout > would be another option). > yes > What is interesting (and we might make that an option) is that the 'no > display' error results in the image being saved 'headfull' so that you can > start it up using a display to debug it (suspended process/debugger). That could be done.. but not as userful as simply report an error. Usually we (developers) knowing what we want to do, and what i don't want to see in my headless image is any attempts to access display/ui. > Saving a headless image headfull can also be done programmatically. > > I don't think more than that is needed. There are many options to interact > with headless images, forcing one on people would not be good, the same goes > for command line parsing, preferences, startup files, ... These other options > could become separate projects. > well, again, when people running image(s) in headless mode, they are know what they doing, and i think their default expectation is that image(s) should be aware that it runs headless and do not try to invoke anything which requires user interaction (like yes/no dialog) , because this does not makes any sense. > I would be an interested user and if I can will try to help. > > Regards, > > Sven > -- Best regards, Igor Stasenko AKA sig.
