Tiling windows in Risc OS

An alternative to the Desktop metaphor of window management is the tiling paradigm,⁰ that where managed windows (not necessarily all) are arranged in a grid, side by side, in an automatic manner, rather than the user dragging and resizing them. Usually this is coupled with keyboard commands for moving between windows and rearranging them.

I got thinking about this when I looked at the source for !Madness in Diversions, which moves windows about, and I wondered if perhaps you could do the same with window sizes. Would it at all be possible with the WIMP?

Off of the top of my head, at a minimal these components are necessary:

1. Identifying windows so that the manager can keep a track of which ones are to be managed and where they should go.
2. Moving windows to new positions (!Madness seems to verify this is possible)
3. Overriding window sizes (including max and min sizes set when created, I think that the SWIs don’t support this?)
4. Using keyboard shortcuts (Meta+arrows and similar) to move between and rearrange managed windows.

Bonus:

1. Focus on windows on “mouse over” rather than “mouse click”
2. Multiple desktops (I’ve seen a program that does this already, I think)

I realise that this interaction pattern is not for everyone, and that it goes against the grain of the assumptions that have gone in to most of the UX design for Risc OS, however, a discussion of the merits of the paradigm is more a matter for Aldershot, I think. The question here is, would it at all be possible and how much would it break?

⁰ https://en.wikipedia.org/wiki/Tiling_window_manager

I’m interested in some of this as well, I’d definitely try out a prototype if you made one.

Broadly speaking a bit of tiling and hotkeys should be possible, but maybe not to the extent of tiling wm’s you’re thinking of.

Overriding window sizes (including max and min sizes set when created, I think that the SWIs don’t support this?)

Even if you managed to do that, applications would get asked to redraw rectangles that they weren’t expecting.

Moving windows to new positions (!Madness seems to verify this is possible)

WindOpen does that as well.

Multiple desktops (I’ve seen a program that does this already, I think)

I use WorkSpace for that.

A little niggle is Wimp_OpenWindow; there isn’t a built-in way to trap that. I think this might be why with WorkSpace when you open switcher (task manager) and then try to open it again on another workspace it briefly flashes on screen.

Focus on windows on “mouse over” rather than “mouse click”

You can probably get FilterManager to do that.

Focus on windows on “mouse over” rather than “mouse click”

You can probably get FilterManager to do that.

There’s a utility – “AutoFocus” (I think), I will have a dig and see what and who and whether the source is there.

Edit: Yep, AutoFocus. No Source, 172 byte RunImage file which appears to do a Wimp_GetPointerInfo and a Wimp_SetCaretPosition

The idea is interesting, but unless you ensured that, say Alt was pressed, it didn’t normally re-assign focus it could annoyingly drift focus all over as you move the mouse.
I suppose you could ensure it did this by modifying the WindowManager code to accept Alt-F as “assign Focus to the window under the mouse pointer”

Focus on windows on “mouse over” rather than “mouse click”

I am not sure that would be a good thing. I still find it very irritating now the filer grabs the focus at every opportunity, and you find your keyboard entry has been going in to a black hole for the last couple of minutes.

I am not sure that would be a good thing.

Understatement of the century there, for exactly the reason stated. At the very least focussing on “mouse over” should be easily thoroughly disabled if it exists at all.

Ah, I see that while I was typing my edit others came up with the same reasons for NOT doing it in a wide open way.

Chris, Clive, can you see the merit of the Alt-F method?

Bit of crappy code that I actually stuck in the Filer Keypress (but that’s only effective if Filer has focus)

focus                                  ; Set the focus to window under the pointer
         MOV     R0,#0
         ADR     r1, mousedata             ; mousedata block where we stash the mousepointer position etc.
gogetpointer
         SWI     Wimp_GetPointerInfo
         LDR     R0,[R1,#&00C]             ; =12 (block posn 12 = Window handle under pointer put into r0
         MOV     R8,R1                     ; protect current r1 (save in r8)
         MVN     R1,#0                     ; clear r1 (no icon setting
         MOV     R2,#10                    ; x offset 10       ; no x offset
         MOV     R3,#0                     ; no y offset
         MVN     R4,#0                     ; no caret setting
         MVN     R5,#0                     ; no index into string
         SWI     Wimp_SetCaretPosition
         MOV     R1,R8                     ; restore our pointer for mousedata block (no mouse droppings) :)
         EXIT

Haha! I really wasn’t expecting mouse focus to be the controversial part! Personally, I’m so used to it, that I find it annoying having to click to focus, but to each their own! Good to know that it is possible, but I agree that it shouldn’t be foisted upon anyone.

I think that what I will try to do first, is a simple rearrangement utility, not aim for a manager, while respecting min/max values (though I am curious to see what kind of undefined behaviours you’d get if you did over-ride those).

EDIT:

There’s a utility – “AutoFocus” (I think), I will have a dig and see what and who and whether the source is there.

@Steve
Is this the one? https://www.vinc17.net/acorn/index.en.html

Chris, Clive, can you see the merit of the Alt-F method?

If I could see a need for mouse-over focussing at all, then yes. I’m willing to believe there may be one, but I’ve never felt such a need.

@Steve
Is this the one? https://www.vinc17.net/acorn/index.en.html

No, that one is better – you’ve got one there that’s 32 bit whereas the one I recalled and found in the stash is not 32 bit. Implemented as a module and you have source. Nice find.

Vincent Lefèvre is a name I recall, but I’ve not seen him active for some while.

Some quick comments.

1. Why add the Alt-F key stroke to gain the focus when a click is surely quicker – the mouse is already being used to move the pointer over the window.

2. The mouse click is often used to place the caret at a specific point, e.g. in the text. How does a mouse over, or mouse over + Alt-F reproduce this behaviour, without needing say a mouse click anyway?

3. How do you prevent the focus being lost, or typing in the wrong document, when the pointer is inadvertantly moved?

If I could see a need for mouse-over focussing at all, then yes. I’m willing to believe there may be one, but I’ve never felt such a need.

Well, if you had a ROM build that included code such that you could navigate the screen moving the mouse with the cursor keys and a modifier then you have focus on the window under your pointer and Ctrl-A selects all files in that window ready to be acted upon as you so wish.
One use off the top of my head.

At a brief glance Vincent has built in different modes changeable with a 4 bit value (e.g. bit 0 toggles enable/disable status)

Why add the Alt-F key stroke to gain the focus when a click is surely quicker – the mouse is already being used to move the pointer over the window.

1. You’re assuming a setup with a mouse in use, rather than a system where the user can move the pointer using modified cursor keys.
2. As above.
3. Don’t press the Alt-F combination.

NB. I don’t think the current setup produces a valid key event on Alt-F but that’s a different issue.

if you had a ROM build that included code such that you could navigate the screen moving the mouse with the cursor keys and a modifier then you have focus on the window under your pointer and Ctrl-A selects all files in that window

I’m not clear how this is any better than the normal way of doing this.

I’m not clear how this is any better than the normal way of doing this.

I would say it’s a 100% improvement on the situation where you can’t do this, and you have no working mouse.
It’s also helpful when you’re in the middle of other keyboard activity because you don’t have to move off the keyboard to operate a mouse (or similar device)

or install mousekey instead.

and you have no working mouse

Ah. I’d not considered that possibility!

when you’re in the middle of other keyboard activity because you don’t have to move off the keyboard to operate a mouse

I believe you, of course – but I’m struggling to imagine what I might be doing on the keyboard that isn’t attached to a window that already has the input focus, or (apart from that “no working mouse” scenario) how the pointer’s moved over another window without me using the mouse anyway.

or (apart from that “no working mouse” scenario) how the pointer’s moved over another window without me using the mouse anyway.

Same answer:

• No working mouse – use the modified cursor keys to move the pointer around
• Don’t want to move hands from keyboard – use the modified cursor keys to move the pointer around.

I stuck some code for that on the forum the other week. I’ve had that for a long while, and it’s had twiddles and tweaks in the lengthy time since I first looked at the possibility.

My biggest stumbling block has been finding a working key combo for the four directions and three for the mouse buttons. First think of a key combination that’s logical, then find one of those that StrongED doesn’t grab…
That’s why I ended up at the Alt + key and wandering off into the dark recesses of the International Keyboard.

I’m used to using the cursor keys to move up or down a line or two within a window, or forwards or backwards a few characters – but the idea of moving into a different window like that doesn’t appeal at all. Hell, if I’m going more than a few characters left or right, or more than a few lines up or down, I go straight for the mouse because that’s quicker and easier. I suppose that might vary from person to person. I’m a fast touch typist on the QWERTYs and numerics, but I find the mouse quicker than long sequences of cursor key presses. That’s even with a mouse – and I’d far rather use a trackerball or a trackpad than a mouse…

Although not really the same thing, I’ll pass on a warning based on something I test-bedded the other day. I was asked to see if we could add “Click on a window to bring it to the front and give it focus” behaviour. Initially it seemed OK – I wrote a bit of C that checked the window that was clicked and brought it to the front etc. I even checked for the nested wimp parent flags and tried to act accordingly.

Then I tried Impression. Each window and toolbar is a separate window (perhaps with pane set) so attempting to alter the window stack order brought panes to the front but not the rest of the window. Oops. I couldn’t come up with an easy way of figuring out the parent window for non-nested-wimp apps (thoughts welcomed).

I suspect this kind of thing could be a problem for auto-focus or tiling window managers. That said, they’re probably not as destructive as altering the window order, provided you respect the pane bit when tiling the windows… but again, knowing parent window would help, and I’m not sure if you can know that without nested wimp?

or install mousekey instead.

I do recall looking at running that. Just refreshed my memory on that one:

1. It uses Alt + NumericKeypad_key, which is a bit of a non-starter testing on RPCEmu on a laptop. Or various of the restricted key systems we have these days.
2. The help file says change the low level key numbers to use different keys with the Alt. Did that tested trying to use Alt-cursor_up/left/right/down – Nothing.
   That could be an artefact of RPCEmu

At the end of the day MouseKey is an add-on people need to find instead of being an OS feature you can enable.
Clive for example could simply not press Alt at the same time as a cursor key and not care, five seconds later a family member could use Alt-cursor_right to move the pointer right without having to download and preload an add-on. Built in choices.

Then I tried Impression. Each window and toolbar is a separate window (perhaps with pane set) so attempting to alter the window stack order brought panes to the front but not the rest of the window. Oops.

Sounds like an Impression bug, but yes that’s why I don’t particularly go with the idea of totally auto-focus.
I want the focus where I left it until I specifically indicate otherwise, in my case when I hit a key combination and when I click a mouse button over the window as alternate ways of working.

so attempting to alter the window stack order brought panes to the front but not the rest of the window.

Just off the top of my head, you probably want to ignore windows that are marked as being panes or don’t have a title bar. Go for the main window, the rest should sort themselves out.

Surely moving the primary window and issuing an OpenWindow event on it – isn’t that what the Wimp does?