Screen Resolution

[Ken Norris]

On May 7, 2004, at 9:00 AM, use-revolution-request at lists.runrev.com 
wrote:

> Date: Fri, 7 May 2004 10:28:49 +0100
> From: Frank Leahy <frank at backtalk.com>
> Subject: Re: Screen Resolution
>
> On May 7, 2004, at 10:11 AM, use-revolution-request at lists.runrev.com
> wrote:
>
>> From: Brent Anderson <brentj84062 at earthlink.net>
>> Subject: Screen Resolution
>> To: use-revolution at lists.runrev.com
>> Message-ID: <BEB6E298-9E26-11D8-8A31-003065A72500 at earthlink.net>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> Hello.
>>
>> Is there any way that you can change the monitor resolution when you
>> run a stack (For example, you run the stack in a 1280X1024 resolution
>> and when it runs the preOpenStack handler, it sets the monitor
>> resolution to 800X600)
>
> Don't do it.  I *hate* programs that mess with my screen resolution.
> I've got a 17" screen and I don't want to see *anything* at 800 x 600!
> Also there are a lot of LCDs (laptops, flat-panels, etc.) that don't
> support many resolutions well or at all, and you could leave the screen
> in a state that makes it illegible or unusable.
==========
I know where you're coming from. It's extremely rude and pretentious to 
change someone else's monitor resolution, even if you change it back 
when closing (IMO _never_ change it without putting it back where it 
was, in any case). However, especially when dealing with web pages, you 
need to keep in mind that many, if not most, student;s home computers 
are second machines running at lower resolutions.

My old 1400 PowerBook, which I use on the internet a lot for emails and 
lazy surfing, etc., maxes out at 800x600.

Having said that, we should probably offer geometry choices. If a 
project is built and locked in at 800x600, which would make for small 
windows on a monitor set at, say 1280x1024, the user might need to bump 
it up so it's readable. Therefore we should offer the user choices of 
_program_ resolution, not mess with their monitor's resolution.

Granted, that's a bunch of extra scripting and tweaking (I believe 
geometry should be hard-coded for professionalism), but I don't think 
anyone should _ever_ (i.e., the only exception being for the scripter's 
personal stuff) change someone else's monitor resolution without 
offering them choices.

I often make fullscreen standalone apps for disabled users. These are 
designed to provide closed environments within which the user has 
customized controls. The method I use is brute-force, but solid:

  On my 17 inch monitor, I'm personally most comfortable at 1024x768. 
Everything looks "normal" to me at that resolution, so that is where I 
create. When I'm done, I redesign the program at additional 800x600 and 
1280x1024 resolutions for the stack files. Because the main window of 
these apps are fullscreen, these are actually separate UI stacks, and I 
always use data and image files for most everything, preferences, etc., 
so it doesn't matter which set of stack files is being used. The image 
controls, for example, automatically resize the images to match their 
size, which have been manually proportioned for each resolution stack.

Here's my method for that:

On startup, the Memory Error dialog contains the engine and the memory 
check (per Richard Gaskin's suggestion) first thing. If there is a 
memory problem, it will (hopefully) display the warning (always at its 
original created res size), and abort continuing to load. It uses a 
"send <in time>" to wait out that process. If it's OK, it doesn't 
display the warning. Then it checks monitor resolution. If it lies 
within the available resolutions, it loads a list of appropriate 
windows (substack files) the first of which is the splash. However, if 
it is not among the available resolutions, it displays a "Monitor 
Configuration Out Of Range" dialog warning that says it cannot load at 
the monitor's current resolution and offers to change it, or to pick a 
resolution for displaying the app (i.e., smaller which is available). 
If the user decides to change the display, it logs the current display 
configuration for returning it to the original on closing, then changes 
it. If the user picks a smaller resolution for the app, it will load 
the stacks designed for that resolution. Then the splash stack for the 
designated resolution opens, usually with some kind of progress thing 
while it loads up all the globals, including all references and 
preferences, menus, and other configurations.

Now the all the app's stuff is fully loaded at the current monitor's 
resolution, or less if the user decided to go with choosing that 
option.

I realize, because of the fullscreen stuff, that this isn't necessarily 
appropriate for every app, but I think the procedure is otherwise 
fairly generic.

HTH,
Ken N