Resize windows from any edge

Has anyone expressed any desire for RISC OS to allow window resizing from any edge of the window? Or is it just me? Every time I am away from RISC OS from a while and have been using other OSs (usually OS X or Linux), it feels odd moving the pointer to that little resize gadget. RISC OS is so mouse-friendly and I like not having to move the pointer all the way to the top of the screen to get a menu item, as I have to do in OS X – so why do I have to move for the resize gadget? (This is even more of a problem now I’m running RISC OS on a Pi at a reasonably modern resolution – if the window is full screen, that can mean a lot of mouse travel, just to resize the window a little).

Is it just me? I did a search of the forums but I don’t see anyone else bothered so it could well be :)

No, I agree. Sounds like a rather desirable feature, especially when you’re not using RISC OS full time.

A resize icon at each corner? That would get my vote.

A resize icon at each corner?

No, Please! I think more usefull would be (like Windows) to be able to resize a window at each of its four sides. As far as I remember there was once a tool for that for RISC OS but it stopped working with some RISC OS Version (4?).

Apart from that I am about to add a new little feature to the Wimp that will save some mouse-meters at resizing a window. I hope I will be ready with this in the next days.

I can’t really imagine a resize gadget on each corner – surely it would add a lot of unnecessary clutter? Unless we aren’t thinking of the same sort of thing.

Matthias – curious to know what you’re adding to the Wimp!

As far as I remember there was once a tool for that for RISC OS but it stopped working with some RISC OS Version (4?).

I had in mind MouseAxess but the description at http://www.apdl.co.uk/riscworld/volume3/issue5/pd/index.htm suggests it did not cover window resizing. I have to say I don’t like most of the things MouseAxess does provide! Now that most of us have to use a scroll wheel for the middle button, having Menu clicks in combination with the others is liable to be tricky as they tend to have different spring strength.

I think adjusting the window size by dragging the edges would be best activated with a key combination. RISC OS left window edges are nice and thin, so anything which solely relied on the position of the mouse would either be exceedingly difficult to use because of the need to target a signgle pixel border, or would interfere with the normal use of applications.

I read an article recently suggesting that the computer mouse would soon be obsolete – that some children are used only to using their fingers with touch-screens or systems that can read their gestures. I guess that many RISC OS users, like myself, have missed out on these developments. This may be slightly off topic, but in discussing the RISC OS GUI it should be kept in mind.

I read an article recently suggesting that the computer mouse would soon be obsolete

I read an article years ago that said the keyboard would soon be obsolete, because of speech recognition.

Anyway, since that time the old buildings have gone the new buildings have new network kit, new PC’s connected to the network and virtually all the voice recognition is done via a system outsourcing the audio file dictation type up to some location on the other side of the globe where a nice cheap human recognises things.

Yes, RO needs to be able to deal with touch screens, particularly being capable of running on things like the ubiquitous tablets.
However keyboards and mice aren’t going away anytime soon.

I dislike the system of resizing windows by dragging edges. It is like eating jelly with a toothpick: fiddly, clumsy and slow, and only gives you one dimension to alter at a time. Give me corner-dragging any day, and enriched so that Select drags as normal but Adjust drags the diagonally opposite corner.

“Give me corner-dragging any day, and enriched so that Select drags as normal but Adjust drags the diagonally opposite corner.”

Absolutely seconded – We’ve already got two resizing methods, toggle and a drag that is superior to the other systems (with opposite side expansion when the edge of the screen is reached). Just enhance these please.

I read an article recently suggesting that the computer mouse would soon be obsolete.

Personally, I find the mouse to be clunky. It isn’t that I am used to my phone, I’ve been using laptop/netbook machines with touchpads, and a well configured touchpad just does everything sweetly. In comparison, the mouse and having to actually hold down buttons and stuff…it seems like a technology from another era. ;-)

I read an article years ago that said the keyboard would soon be obsolete, because of speech recognition.

Keyboards will be around for ever. Even Ghost In The Shell with its ability to jack into networked things with your brain has keyboard-using secretaries. Okay, there’s like sixty keys and nearly as many fingers, but…

Seriously, I can’t understand heavy Scouse and I’m a person, not a machine. Speech recognition is more or less still a toy (there’s a blog article back in 2011 [ http://www.heyrick.co.uk/blog/index.php?diary=20110602 ] that was written by “speaking” via Google – accuracy wasn’t terribly). Frankly, the keyboard is our quickest input method, though I do predict a revision to work on a keyboard for enhanced speed, not the QWERTY arrangement we’re used to now.

As for resizing windows, both methods have their good and bad points. It is useful to be able to drag a window to a larger size from any corner, but it is annoying to have to home in on a narrow border in order to do it (doubly so when if you miss, you could have some totally unrelated thing pop up on top). The draggy-corner is cool in that you can resize in two dimensions, but you need to have that corner visible. The only thing I would ask is that if you drag with Adjust, it will move the top and the left. It might be a bit jarring at first but it fits into the RISC OS Adjust-does-the-opposite and would give one place to allow complete control over window resizing (suck on that Windows!).

The drag-from-side can be added as an option. FilterManager can handle this. I had something from AcornUser a billion years ago that did exactly that, using FilterManager…

I seldom use RISC OS these days but when I do it’s almost always on my iMac. My iMac has a Magic Trackpad which I use instead of a mouse. I find the trackpad much more comfortable than a mouse and it works wonderfully in RISC OS. The only thing I have to use the mouse for is the middle button. I believe that gestures are the future.

I wrote a program whose window could be resized from any edge – see pic. It only works nicely when you have some margin anyway. The typical RISC OS document and filer style windows never have a left margin.

However, they usually have window furniture that could have additional functionality. Adjust-back to bring-to-front should be standard by now, but one could imagine drags on the corner icons (normally left, back, toggle but depends upon configuration) being interpreted as a resize (given a certain amount of dead-zone to avoid unwanted resizes.

Making the scroll buttons work would require a delay too: Given the three actions – click, drag and hold – a click (and release within the delay) has the normal behaviour, a drag (moving by a significant amount before the delay is up) starts the resize, a hold (click and hold and no significant movement) has the old behaviour (scrolling).

“Give me corner-dragging any day, and enriched so that Select drags as normal but Adjust drags the diagonally opposite corner.”

Absolutely seconded – We’ve already got two resizing methods, toggle and a drag that is superior to the other systems (with opposite side expansion when the edge of the screen is reached). Just enhance these please.

Vetoed. Select- and Adjust- drag on the resize icon already have two different functions and I don’t think we should lose either of them for the frankly bizarre behaviour of dragging one thing to make something else move. There are so many problems with that paradigm – do you constrain the pointer by the existing screen edges?; do you temporarily move the pointer to the opposite corner?; do you make the pointer disappear?

I don’t understand the problem anyway – resize a large window towards an edge of the screen and it will resize ‘away’ from that edge anyway (unlike any other OS) so what problem would this feature solve?

“Select- and Adjust-drag on the resize icon already have two different functions” . Yes, Select-drag is accompanied by a move-to-top-layer, Adjust-drag is not. I humbly retract my suggestion. Those two functions are useful.

Ah… I didn’t know that. I think it would be useful to keep any changes as simple and as intuitive as possible so that we don’t end up with extra seldom used window dressings in keeping with the rest of RO.

Going off on a tangent a bit, we could do with a wiki page listing all the different mouse & keyboard interactions which are possible in the desktop. The trouble is that I can’t quite see where this page should fit into the wiki – it looks like we could do with a new section somewhere for user documentation. And perhaps this information has already been collated for the updated welcome guide? (which I’m assuming will appear online somewhere once complete – perhaps on the wiki itself, so we might be jumping the gun a bit by creating a page/section now)

The kind of information I’d expect to see would be:

• General window interactions
• Icon bar interactions
• Menu interactions
• Filer interactions
• Standard keyboard shortcuts/hotkeys within apps

The wiki page is a good idea. Incidentally, the Select/Adjust differences mentioned above apply to drags on both the titlebar and the resize icon. I knew about the former many years ago – it would elicit gasps of envy from PC users when I demonstrated dragging one window behind another – but I only discovered the latter when I experimented after reading nemo’s post. So, thanks nemo.

Yes, there are a surprising number of people who still don’t know about some parts of the Wimp’s functionality, in some cases after using RISC OS for years.

Since the opportunity has arisen once again: Does anyone here not know that clicking Adjust on the close icon will open the parent directory of a document or Filer view? That one usually elicits at least one surprised response.

Hence my surprise when I use a version of the WindowManager that doesn’t implement Adjust-click on the Back icon as a bring-to-front.

The Select/Adjust consideration should (IMHO) be considered by any author writing RO software – eg where Select on an “OK” button should do something and close the dialog, Adjust should do it and not close (whereas Windows requires the additional “Apply” button to achieve the same effect). Select on a “Cancel” button should obviously close a dialog, but Adjust should instead reset the contents of the dialog to how they where when opened. Similarly, Adjust click on an up arrow means “down”.

RISC OS’s GUI has always been ‘overloaded’ in this sense. It’s concise and powerful, but not obvious to the uninitiated. Thankfully the help (!Help or my preference BubbleHelp) can point these things out.

we could do with a wiki page listing all the different mouse & keyboard interactions which are possible in the desktop

Hold that thought. I’ve been doing similar stuff for the RPi disto so once that’s out, you could probably import my stuff into the wiki somewhere and build upon that.

And here’s a rough start on that wiki page I was thinking of: https://www.riscosopen.org/wiki/documentation/show/Desktop%20interaction%20quick%20reference

(Emphasis on “rough”!)

Out of curiosity, is there a way to PREVENT the automatic opposite direction expansion? (I find it highly annoying when I’m manually tiling windows, because I can’t just slam against the window edge.)

Adjust-drag doesn’t do it (at least on 4.02, which is what I’ve got in front of me right now, not sure if modern ROOL builds do the same).

Getting back on topic, this has been brought up before at Touchscreen tablets may require larger window furniture sprites.