Large dialogs on small screens

Separate thread to avoid confusing the other one.

There’s always been a design failure in the Wimp regarding dialogs – windows without scrollbars – if such a dialog is larger than the screen when it is opened (either initially, or when the Wimp changes mode), then the dialog is typically constrained to the screen size.

This is usually catastrophic, as not only do parts of the window immediately disappear, but applications will typically never fix the dialog even when changing to a larger mode – it stays truncated.

This can be avoided in a number of ways:

• Setting b6 “no bounds”
• Setting the minimum window size appropriately (typically 2,2)
• Ignoring or overriding such OpenWindow requests

However, that doesn’t make the dialog usable, as parts off it will be off screen. Again, that can be mitigated by allowing any part of the window to be dragged to move it (as some applications allow anyway).

I’ve always though it a shame that the Wimp did not spot such constraints and automatically add scrollbars to the window, by embedding it in a scrollable parent which would otherwise pretend to be the original dialog.

It’s conceivable such behaviour could be retrofitted.

I noticed this really early on when I was using S-video from the Beagle, at some silly low screen size (what is it, 702×564 or something? wait, interlaced, more like 2xx but 2:4 aspect).
Quite a number of windows (hello system config!) don’t fit. And given the action buttons are usually at the bottom…

Pushing in scroll bars would be an interesting idea, certainly.

Quite a number of windows (hello system config!) don’t fit

I found this when using some small monitors at 640×480. The dialog to set screen size is unusable because the action buttons are off the bottom, and there’s no way to move the window up.

And the Style Guide says…

Make sure your application supports VGA resolution at 640 by 480 square pixels

;)

The dialog to set screen size is unusable because the action buttons are off the bottom, and there’s no way to move the window up.

I was going to point you at the AltClick module I ported, which would have allowed you to drag a window partially off the top of the screen to be able to see the buttons at the bottom (as long as that Window behaviour has been set in !Configure). But unfortunately at some point it has stopped working with RISC OS 5.

And the point is that unless the task in question has taken special measures to prevent the window being resized-to-screen, it will already have been squished before AltClick could get near it (and stays squished when returning to a larger mode).

And the Style Guide says…

Make sure your application supports VGA resolution at 640 by 480 square pixels

My grandfather used to irritate my mother by pointing out that the house rule was “do as I say” not “do as I do”
Clearly, this follows the same line of thought.

And the point is that unless the task in question has taken special measures to prevent the window being resized-to-screen, it will already have been squished before AltClick could get near it (and stays squished when returning to a larger mode).

If it’s a non resizable window it should open at the position and size set in initial OpenWindow, with the top left forced on screen, but still larger than the screen.

I notice the !Configure Window window will gain a scrollbar if it is larger than the screen, which would be the model to go for.

Just switched to 480×352… this isn’t going to end well:

Thought so:

The biggest problem is the window for configuring your monitor, where you can’t save the settings if the current monitor/mode is small enough that the Save button is offscreen. (I think this happens when !Boot goes wrong and it defaults to VGA 640×480)

The biggest problem is the window for configuring your monitor, where you can’t save the settings if the current monitor/mode is small enough that the Save button is offscreen.

Fortunately that was fixed in October 2012 by the addition of a vertical scrollbar, so hasn’t been an issue for some years now.

Couldn’t the Wimp be persuaded to scroll such dialogue boxes as the pointer touches the edge of the screen?

Autoscrolling or (easier) scrollbars both require the Wimp to preserve an additional rectangle – a Window’s rectangles are:

• The work area (the insides of the window)
• The visible area (that part of the insides you can see)
• The outline (with all the furniture)
• Previous visible/outline (for size toggling)
• Minimum size (only a width/height)

The permanence of the problem is caused by windows generally not having a Minimum Size (it’ll be 2,2) so they get squished by the small mode. Once squished, the Visible Area changes – permanently.

To have temporary scrollbars (or autoscrolling) on such a dialog would require the Wimp to effectively retain the desired Visible Area as well as a constrained Visible Area (and it’d have to remember the unconstrained window flags in addition to the constrained window flags with scrollbars).

The simplest way to do all that is to nest such an oversized dialog inside a scrollable parent – the dialog’s Visible Area is then protected, and the temporary parent can be as small as necessary – its Work Area is the dialog’s Visible Area.

As I say, this could probably be retrofitted by some devious third-party without changes to the Wimp (which is the best solution really), but it’s also possible to imagine the Wimp doing something similar automatically.

Sprow suggested

Fortunately that was fixed in October 2012 by the addition of a vertical scrollbar

And what happens when the mode is too thin?