Wimp behaviour when resizing windows
Pages: 1 2
Jon Abbott (1421) 2651 posts |
This sounds like a bug in WindowManager to me, but I’m going to assume its something apps are doing wrong when creating windows. If you drag the left part of a resizable window off-screen and then drag to resize it, WindowManager moves the left side back onto the screen. Is there a flag to stop it doing this? My interpretation of the window flags is that WindowManager should only do this if bit 13 is set? It makes resizing a window that doesn’t fit fully on-screen impossible. |
Paolo Fabio Zaino (28) 1882 posts |
@ Jon
I can confirm that it most likely it’s a bug in the WindowManager, or at least a weird behavior. In my Launchpad I expressly: - set flag 6 to 1 But yes, moving Launchpad window a bit off screen on the left and then try to resize it will still trigger the behavior as if flag 21 and/or 13 were set to 1, which it should not as far as I understand. |
Bryan (8467) 468 posts |
It isn’t just the left side of the screen. The same effect is seen on all four edges of the screen. |
Bryan (8467) 468 posts |
I do not see that problem. (5.28 on a Pi 4) |
Chris Hall (132) 3559 posts |
Clicking the bottom right of a window that has its title bar off screen is the only way to get it back on screen. So it is a useful bug. |
Jon Abbott (1421) 2651 posts |
Open a Window, make it the width of your desktop resolution, drag it off the left side of the screen and then try to make the Window wider than the screen width…you can’t because the left of the Window springs back on screen, meaning you can only ever manually resize a Window to the desktop resolution…which is a bit annoying if you’re running at a low resolution.
There is that, but there’s a Window flag to prevent that occurring. Once opened you can’t drag a window off-screen to the point you can’t get at the title bar to move it. What I can’t work out is how it tells the difference between a Window that’s been moved off screen – which is allowed, and a Window that’s being resized off-screen – which isn’t allowed. Even if you fix the Window position offscreen when the WimpPoll returns with the open window request, it still springs back onscreen when resizing. |
nemo (145) 2556 posts |
OK, there’s a load of stuff here. Jon said
Yes there is: Window Flags bit 6 “No bounds”. Paolo thought
It’s not a bug, though there’s a degree of historical artefact about it, as we’ll see. Jon continued
This is a different thing, and is much more interesting. Originally b6 did something much more restrictive – windows were kept completely on screen unless b6 was set. This was relaxed in RO3 so that you could move any window to the side temporarily, which meant that the bit that used to keep the window on screen no longer kept the window on screen. However, it was believed that if you were resizing the window then obviously you’d want it all on screen or why are you resizing it? This isn’t a bug, it’s a GUI design decision. Because some windows really did have to be kept on screen, bit 13 was introduced to mean “No really, keep this window on screen”. So b13 did what b6=0 used to do in RO2 and Arthur… but only when b6=0. If b6=1 (“no bounds”) then the window can go off screen regardless of b13. When b6 “No bounds” is set, then not only can the window be dragged partially off the left of the screen, it can then be resized off the left of the screen too, losing it completely. I regard this as a bug, and there’s an opportunity to enforce b13 “Stay on screen” here to refer to the pointer, meaning the window would resize but keep its edge on screen. However, if the extent of the window is larger than the screen size, moving the window off the side of the screen does not allow the pointer to size the window larger than the screen. Again, that’s intended, but not necessarily helpful. Note that windows certainly can be larger than the screen – this restriction only applies to DragType 2 – resize window. Setting the size of a window manually via Wimp_OpenWindow (which anyone can do regardless of ownership these days) allows a window to be made any size… but amusingly if a window is already larger than the screen, and is off the left so that the resize icon is accessible, then attempting to resize it with the pointer will apply the screen-size constraint and drag the pointer off the left of the screen. Again, deliberate but unhelpful. There are various work-arounds including nesting your own ‘resize’ icon in the corner, and resizing the parent window accordingly as that pane is dragged. Another is to keep a record of where your window was and pay attention to the window flags and parameters of the OpenWindow request during a resize and simply override the Wimp’s suggested coordinates. But none of these things can be applied universally. The current behaviour is partly an artefact of the RO3 finessing, and partly conflict between flexibility and the danger of losing a window off screen – I hardly need point out that the whole purpose of scrollbars is to enable a larger-than-screensize area to be accessed… trying to do the same by dragging a larger-than-screensize window off the side of the screen is somewhat contrarian. However, there’s another point here, and one I’ve long regarded as a deficiency (though it is much less important now) – large dialogs on small screens. This is usually catastrophic for various reasons, and as it’s a different subject with different solutions, I’ll start another thread for that. |
David J. Ruck (33) 1636 posts |
If lost it should come back on if you change to a mode with a different (lower?) resolution. |
nemo (145) 2556 posts |
Not if b6 “No bounds” is set – once it’s offscreen it stays offscreen. |
David J. Ruck (33) 1636 posts |
Probably why some applications constantly force their floating tool panes back on screen, even if the window they are associated with has been moved off screen by !Workspace |
nemo (145) 2556 posts |
Hot-key capture windows need to stay offscreen, so there’s an interesting heuristic to be spun there. |
Jon Abbott (1421) 2651 posts |
That was the first workaround I attempted. Before performing the Wimp_OpenWindow, I reset the left coordinate in the Poll block back to the window’s previously negative value. That appeared to end up with a Window that’s left coordinate was negative when read back, but visually on-screen was 0. I need to attempt a Repro, to see if it wasn’t an issue with my code or the version of Window Manager I was using at the time. |
nemo (145) 2556 posts |
There used to be a race condition in the Wimp that resulted in all multitasking stopping unless (and until) your task opened a window exactly where the Wimp asked it to (including Z-order). That was fixed decades ago. So it is always possible to respond to an OpenWindow request by opening the window somewhere else. Also note that if you set b6 to enable the window to be resized off-screen and then toggle it off again, the window will get pulled back onto the screen. Grrr. |
Jon Abbott (1421) 2651 posts |
That comment, combined with messing with a Repro led me a workaround:
That then results in a Window that initially opens on-screen, but can be resized off-screen. A bit convoluted I confess, but works. So the actual issue is not what I originally thought. The issue is with the behaviour of Wimp_OpenWindow when b6 is unset – it lets you drag the Window off-screen, but the documentation would imply that shouldn’t be possible. |
nemo (145) 2556 posts |
<gets out the usual soapbox and stands on it>
That’s unnecessary unless you want compatibility with very old Wimps – you can change the window flags using OpenWindow. So you can “open the window with b6 clear” and then immediately “open it with b6 set”:
Note the use of the “nested” API to set the window flags too. |
Jon Abbott (1421) 2651 posts |
I need to support a stock RISC OS 3 Archimedes, so can’t use any of the later Wimp additions. Admittedly, I have put some code paths in where it makes sense – updating Icons for example, but I don’t think I need bother here as it only happens once when the window is initially created. |
nemo (145) 2556 posts |
Cool.
Quite so. |
Bryan Hogan (339) 593 posts |
Small request Nemo – when posting code examples could you spare a thought for us feeble humans and use the SWI names rather than numbers :-) |
nemo (145) 2556 posts |
Apologies. Done. |
Steve Pampling (1551) 8172 posts |
Leaving the semi-magic string of characters, of course, because everyone knows what that spells backwards. |
Rick Murray (539) 13851 posts |
Why is “TASK” used? This was introduced in RISC OS 2 to denote a Wimp “task”, a program that runs in a multitasking manner. If one is to omit the “TASK”, they’ll get a weird sort of singletasking frankenWimp as the thing attempts to offer you the full Arthur experience. As to why “TASK” is used for all sorts of other changes, well, it’s &4B534154 in a memory word that must exist for Wimp Init, so it’s just as easy to pull it into a register and compare when wanting to do other enhancements, such as selecting the extended version of OpenWindow. |
nemo (145) 2556 posts |
There are a number of APIs which having not been designed with future expansion in mind, had no way of indicating that exciting! new! registers! had been added – such as via a flags word – so a special magic value is used that is theoretically vanishingly unlikely to already be in that register. You can see why using the same magic value for different SWIs would be a forehead slapper, hopefully. Then we get to the wonderful example of Wimp_PlotIcon, which was expanded in RO4.3 via, yes, the same TASK magic number but they screwed up the registers resulting in R5 being interpreted both as the Y coordinate and as a flags word. At the same time. So they fixed that by changing to a different magic number… which is “KSAT”. Cos they got the first attempt arse-backwards. FTR I don’t think it’s a good idea to use the same magic in different SWIs, and I also don’t think it should be all uppercase or lowercase, just in case. |
Steve Pampling (1551) 8172 posts |
(Quirky query1) True, but why? 1 I’m in that kind of mood right now – Chris has a thing on the TV (Youtube) showing the “Rush, Freewill” take on musical time signatures. |
Stuart Swales (8827) 1357 posts |
A value that would be very unlikely to be in that register otherwise. Except when it’s used all over the place (Nemo speaks truth, they all should have been different if extended this way rather than with foresight). |
Rick Murray (539) 13851 posts |
Because it was a flag to tell the original Wimp that it was a multitasking task. Because, previously, the Wimp Initialise call took nothing on entry (Arthur PRM book 2 p448), the registers could be anything. Because of this, it was deemed necessary to use a specific unique word that wasn’t liable to be there “by accident”. That this word crops up in other places is, perhaps, laziness rather than anything else. Though I think one of the colour calls uses “WIDE”, perhaps as “TASK” is a bit nonsensical? |
Pages: 1 2