Large dialogs on small screens
nemo (145) 2552 posts |
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:
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. |
Rick Murray (539) 13850 posts |
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). Pushing in scroll bars would be an interesting idea, certainly. |
Alan Adams (2486) 1149 posts |
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. |
Rick Murray (539) 13850 posts |
And the Style Guide says… Make sure your application supports VGA resolution at 640 by 480 square pixels ;) |
David J. Ruck (33) 1636 posts |
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. |
nemo (145) 2552 posts |
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). |
Steve Pampling (1551) 8172 posts |
And the Style Guide says… My grandfather used to irritate my mother by pointing out that the house rule was “do as I say” not “do as I do” |
David J. Ruck (33) 1636 posts |
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. |
nemo (145) 2552 posts |
Just switched to 480×352… this isn’t going to end well: Thought so: |
Theo Markettos (89) 919 posts |
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) |
Sprow (202) 1158 posts |
Fortunately that was fixed in October 2012 by the addition of a vertical scrollbar, so hasn’t been an issue for some years now. |
Simon Willcocks (1499) 519 posts |
Couldn’t the Wimp be persuaded to scroll such dialogue boxes as the pointer touches the edge of the screen? |
nemo (145) 2552 posts |
Autoscrolling or (easier) scrollbars both require the Wimp to preserve an additional rectangle – a Window’s rectangles are:
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
And what happens when the mode is too thin? |