Window „Docking“

One of the things I really like RISC OS for, is the „ergonomics“, working with multiple windows/the filer. What I mean by this are the different ways to browse through directories back and forth and keep multiple windows open, or just one etc. The same for grabbing windows and move them in the background, without calling it to the foreground. The only thing I‘m missing is a shortcut for window docking, as Windows and many Linux desktops are offering – so to place a Window in the exact left half of the screen by pressing Win+ArrowLeft for example. I find this easy way to split the screen between two applications very useful.

…to place a Window in the exact left half of the screen by pressing Win+ArrowLeft

I never knew that, and it’s very useful indeed.
For RISC OS however, it would imply that every individual program intercepts that keypress and reacts accordingly, due to the cooperative nature of the OS. In other words, every program should be extended with some appropriate code in order to let it work.
Or would it be possible to create a module that changes size and coordinates of any active window? I’ve actually no idea.

WinSnap ?

For RISC OS however, it would imply that every individual program intercepts that keypress and reacts accordingly, due to the cooperative nature of the OS.

Apps mostly only do what the Wimp tells them to do as far as their windows are concerned, so it should be possible to implement this via the “usual” methods. The most likely approach would be to filter Open_Window events and fiddle with the information passed on to the applications.

Or would it be possible to create a module that changes size and coordinates of any active window? I’ve actually no idea.

WindOpen already does this, so “all” that needs to be added to its approach is the code to detect the mouse gestures.

WindOpen just uses standard Wimp SWIs to enumerate windows and then send open messages to them, it’s designed for use from the command line and scripts. So please don’t use it from an apps, as it’s easier and better to use the SWI calls directly.

So please don’t use it from an apps, as it’s easier and better to use the SWI calls directly.

“so “all” that needs to be added to its approach”… I clearly wasn’t suggesting using WindOpen, just noting that the necessary control was possible with an example of such a tool.

However the windows behaviour when dragging windows around has annoyed me more than once.
First when Win 7 came out and I didn’t know about it, dragging a window near the top kept making it full size. Once shown how to drag to the side to make half screen, I found useful.
Then Windows 10 came along and broke this. Dragging a window to the side does make it half-screen, but it also shrinks all the other windows instead of leaving them for the user to adjust. Bah, humbug.

Windows key plus each arrow key does something. Using them in succession produces some, erm, surprising results.

Could be…interesting.
You’ll need to ensure it is only applied to windows with scroll bars, and understand that it won’t work with everything. I can think of several apps where the scroll bar is pasted in later. Hmm, and I wonder if it’d push Draw’s pane off screen?

For RISC OS however, it would imply that every individual program intercepts that keypress and reacts accordingly, due to the cooperative nature of the OS.

I don’t think that’s correct. Applications are agnostic as to the position of their windows – they simply redraw them according to redraw requests from the wimp, when their window is moved or resized. The actual moving and resizing is handled by the wimp. And that’s all that should happen in the if we had window snapping. (And I now realise that Steve’s already said as much!)

As for other issues mentioned:

You’ll need to ensure it is only applied to windows with scroll bars,

Windows that can’t be resized should be repositioned appropriately.

Related to that, windows that have a maximum size that is smaller than the area they would be snapped to should be repositioned accordingly, and enlarge to that maximum size. And windows that have a minimum size that is bigger than the area they would be snapped into should be repositioned and resized to that minimum.

and understand that it won’t work with everything. I can think of several apps where the scroll bar is pasted in later. Hmm, and I wonder if it’d push Draw’s pane off screen?

What should happen with Draw is exactly what happens now if you drag its window to the left hand edge of the screen; the toolbar overlaps the left hand edge of the window. (The same happens with Artworks).

Having said all that… I think the advantage of window snapping on Windows comes from the way Windows is commonly used, with the active window at the front and (often) either very large or full screen. RISC OS is normally used with smaller windows to start with, and the active window doesn’t need to be at the top of the stack. I’m therefore not entirely sure what it would necessarily bring to the OS in terms of benefits.

And that’s speaking as someone who uses it a lot on both Windows and Linux as a quick and easy way to position windows for certain tasks. For example, when I’m at the office tomorrow using my Windows 7 computer, most of the day I’ll have my accounts software on the left hand side of the screen, and email on the right – but at certain points, I’ll need slightly different arrangements (for example a web browser on the left hand side, and top right showing a particular report from the accounts software, and the bottom right a particular window from that software).

All quickly positioned using snapping – or at least partially so; Windows 7 doesn’t do quarter screens with snapping – so it’s a case of snapping to one side then fine tuning from there. Windows 10 does do quarters, as does the window manager I’m using for Linux Mint – other Linux distros and window managers may vary.

WinSnap, linked by Raik, looks to me to be subtly different to window snapping in that sense, based on what its help file says; it makes it easy to align window edges with the screen edge – rather than actually snap a window to a particular edge and resize it. I wonder if there’s an idea there for a subtly different approach; snap to a given edge (or corner) in the way Windows/Linux do, but without resizing windows.

Ah, so that comment did appear last night.

(Deletes text file saved last night when the site stopped responding while attempting to post it.)