Bring a window to the front by clicking in the menu title

One persistent difficulty with the RISC OS Desktop UI is that of bringing a window to the front when all the few controls that do this are obscured.

You can almost always get a tiny square of exposed window to open a menu and while its not an obvious behavior, if clicking in that menu’s title brought the window to the front it would be significant improvement.

I was thinking of coding a quick example app in basic that didn’t do anything but demonstrate this behavior but really if the wimp did this for all apps that would be better still.

Alan

Might one way of doing this to be have a Wimp window management menu, invokable maybe thru Window-key+Menu-click?

Bring to front
Bring forwards
Send to back
Send backwards
Close (usual keyboard modifiers)
Minimise
Maximise
etc.

Yes, I know that ancient keyboards don’t have a Windows key, but let’s try to make progress here.

In my own programs, a click on the iconbar icon brings the window to the front. This works even when the window is completely hidden.

It does require the application itself to do it though.

I think it is an important RISC OS UI feature to NOT bring windows to the front when clicking any old stuff (like menu entries or the menu title). Personally, I use Mauser (others use MouseAxess), which provides a general menu+select functionality to bring-to-front-and-drag-to-move-whereever-your-mouse-is. Or of course menu+adjust for moving without changing the window depth (another great RISC OS UI feature). Others use some Alt-Tab task switchers.

Stuart’s suggestion also sounds good to me – use a dedicated keyboard modifier to make the “bring to front” thing an explicit user action. This might work as a general WIMP solution, because it does not suddenly introduce implicit side effects to existing operations.

As a side note:

On my DME project, I have implemented already ways to bring windows to the front without relying on the specific button. The keys/mouse combination is fully configurable (and at some point should also be handled by the Global Shortcuts component).

The reason is not yet available is simply time and testing with multiple apps that do not adhere to the Style Guide and so do not respond correctly to the tool. However it works fine for most of the apps (included nested windowing and also complex windows structures which are not easy to handle and require to “navigate” the window stack).

Hope this helps

I think it is an important RISC OS UI feature to NOT bring windows to the front when clicking any old stuff

Me too, but the menu title bar is not just “any old stuff”. OK, you might like to drag it around, but a drag doesn’t have to bring the associated window to the front, just a click.

The user story doesn’t resonate with me, but I can see it being useful if you can’t see the title bar (or resize icon). It’s worth considering (and could always be an option, like “Real time redraw”).

I have used a small module for years which enables Alt-Select on a window to bring it to the front – and it can also be dragged. Alt-Adjust drags the window but preverves the depth.
It is DragWindow 0.03 (30 Jun 2003) 32bit Thomas Hawtin

However, I have no idea where I got it from!
A quick Google later I have found https://github.com/tackline which seems relevant – and it contains DragWindow … but only v0.01 (15 Oct 1995) which is NOT 32 bit.

I find the facility very useful, and would not want to be without it!

I have used a small module for years which enables Alt-Select on a window to bring it to the front – and it can also be dragged. Alt-Adjust drags the window but preverves the depth.
It is DragWindow 0.03 (30 Jun 2003) 32bit Thomas Hawtin

I’m pretty sure there is more than one module/utility to do the selection of a specific window from the stack and bring the selected item to the front.
I would have said, perhaps someone could look at the methodology and replicate, but it looks like Paolo has already done everything except test it to death and pick out the non-conformist apps where fixing the app might be a better option (if possible)

It is DragWindow 0.03 (30 Jun 2003) 32bit Thomas Hawtin

I have found DragWindow 0.02 (30 Jun 2003) 32bit Thomas Hawtin on an Iyonix backup. It arrived here by email, for testing.

@ Steve

it to death and pick out the non-conformist apps where fixing the app might be a better option (if possible)

Yes, so I have started from testing what was available (I am not a fan of re-inventing the wheel!). However, the majority of the utilities/modules were either not 32 bit (and no source to be found and I really want to ensure everything in the DME project is maintainable by the community even in the case I may get bored and leave, or accidents etc) or (the problem) they were linited to either a window under the mouse (for the worst implementations) or to a simple reverse browse of the child window (for the sligthely better implementations).

Now, this presents few problems:

1) There are apps which tend to manually “attach” two windows together (absolutely wrong approach, but it exists)
2) Furniture might be the “little bit” visible that djp is mentioning and that would not be the main window
3) Reverse browsing the nested child is not enough to figure out the main window, for instance we need to check also if that is The window with the titlebar and icons, because sending the message to the wrong window will result in being either ignored OR produce bad visual artifacts
4) So, there is a need to also use Wimp_Extend and verify we have found the right window (from the application point of view)

Hence, I have “bitten the bullet” and rewrote the whole thing. I have now code that is very capable, but, as mentioned, I need to test all the edge cases (which on RISC OS are always the majority! Damn democracy of coding lol – joking!)

On top of that, there is the average RISC OS user which is always opinionated (it’s ok I love you guys anyway) and so no-single key combination/mouse action fit them all, hence I am adding full configurable possibility (pretty much like on Launchpad). Default will have a configuration and, for the most “demanding” RO users, they will be able to re-configure it as it please them while having a tool that can detect most of the windows that need to be sent to front/back etc. correctly even for the most creative developers approaches XD

Sorry for the slow progress, but I had some very thought personal stuff going on for a while and very little time for RISC OS, plus the amount of things needed is huge! :(

Yes, so I have started from testing what was available

Like, functionality in MoreDesk, old Hensa available files: AltTab, Cycle, BackIcon, CoolSwitch, Barman (the old references, indexes and sometimes files I store away “just in case” is almost as the “stuff” in bedroom 3 and the garage)

I’m pretty sure there is more than one module/utility to do the selection of a specific window from the stack and bring the selected item to the front.

I ported AltClick by David Walker, downloadable from https://armclub.org.uk/32bit/

I ported AltClick by David Walker

In RiscPCEmu RO 5.4 I get an error with the module.
SWI &1E returned a bad error pointer.
I dont use internet in the Emulator, and I have a simplified !Boot (about a dozen lines) but modules should just load I think.
I have used AltClick before on native machines.

SWI &1E returned a bad error pointer.

When are you running it? In !Boot…PreDesk or …Desktop or double clicking? Mine is in PreDesk.

double clicking

Yes, that error is omly when double clicking. Checked and the module is loading happily from !Boot, (before desktop).
It just isn’t responding to alt click on this setup. I will try it on my parallel RISC OS 3 RiscPCEmu program and report back.
Edit: My similar RISC OS 3.7 RiscPCEmu doesn’t respond to Alt either, As long as you have it working on RiscPCEmu it must be something to do with my keyboard recognition/ driver.
In Zap Editor, if I press Alt x I get a full height ‘>’ on screen, also in !Edit. Shows that alt key is alive at least.
If I unplug the usb mouse, the laptop touchpad mouse doesn’t work with alt (for AltClick) either.

It just isn’t responding to alt click on this setup.

The setup. my Peppermint Linux laptop, is already using AltClick for window moving from anywhere in the window. Like the windows key though, it doesn’t stop working when the focus is in RiscPcEmu.
I couldn’t find a setting for it in the gui settings, but anyway it turns out better for positioning RiscPcEmu higher when it starts, rather than finding the top bar.
Edit: Cntrl Click in linux appears to be per app focus based, probably already used in RISC OS too?

I remember using a module back in the 90s called ‘AltClick’ which added that functionality. Didn’t change the normal stack behaviour, but click anywhere on a window with the left Alt key held down and it would bring it to the front of the stack (as if you’d clicked on the title bar).

I always maintained that functionality should have been added to the Window Manager as it should have been there from the start. This was before Acorn released WIMP 3.98.