Wikipedia:Reference desk/Archives/Computing/2023 March 17

From Wikipedia, the free encyclopedia
Computing desk
< March 16 << Feb | March | Apr >> March 18 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


March 17[edit]

Procrastination with installing updates[edit]

When software updates are asked to be installed, a "Remind me later" (or "Ask me later" or something similar) button often appears, which could be seen as procrastination. So, is there a reason that software update popup windows often include such a "procrastination" button (besides being "annoying")? Procrastinating with the installation of updates would of course lead to risks. GeoffreyT2000 (talk) 14:17, 17 March 2023 (UTC)[reply]

If you are about to go onto a zoom call, and an update takes many minutes to complete, you wouldn't want to start the update then but you do later. Or if you're analysing data that takes days you probably don't want to install an update until your code finishes. Dja1979 (talk) 14:46, 17 March 2023 (UTC)[reply]

How do people switch windows these days?[edit]

Sorry for the basic-looking question, but please bear with me.

Once upon a time, when multi-window displays had just been invented, you made a window active by clicking in it with your mouse. And then, once it was active, all its buttons and other controls became active, and you could start clicking on those.

Evidently some users found this a nuisance, because designers began special-casing some of the window controls, so that if you clicked on them in an inactive window, they acted immediately. (Stated another way, clicking on such a special-cased control does two things: it makes the window active, and does whatever the control does.) At first I think it was just the close box that behaved this way, but these days, more and more (perhaps all) controls seem to behave this way.

These days, there are also other ways to switch windows. I think Alt-Tab is pretty popular, and there are also things like the "Dock" under MacOS.

So, these days, I find that clicking in a window to make it active is tricky and dangerous. It can be tricky to find a bit of an inactive window that's exposed but not part of a special-cased control. And if I goof, or if there's some control that's invisible when the window's not active, clicking in a window like this can have arbitrarily bad — and sometimes unknowable! — consequences.

So I've come to conclusion that nobody — except me — ever clicks in windows to make them active any more. If they did, the danger it poses would be complained about, and designed around. Instead, everything's moving in the other direction: there's more and more window content that's active, and that's active even when the window's not active, and that's invisible when the window's not active or the mouse is not over it.

If I'm right, if nobody's clicking in windows to make them active any more, the feature could safely be removed entirely. No one would notice, except for me, and I'd be annoyed, but at least I'd be protected from my mistakes.

Or, if (as seems likely) my analysis of the situation is off-base, can someone explain what's really going on? —scs (talk) 19:21, 17 March 2023 (UTC)[reply]

If I'm concerned about that sort of thing, what I do is click on the title bar. --174.89.12.187 (talk) 19:45, 17 March 2023 (UTC)[reply]
You're not using the systems I'm using!
Have you not encountered "modern" applications with all sorts of helpful little tools shoehorned onto the title bar? I regularly find myself using applications for which there's not a single pixel in the title bar that's not active in some way. (Also, it's often the case that the only visible bit of the window I want, that's not obscured by all the other windows I've got open, does not include the title bar.) —scs (talk) 20:20, 17 March 2023 (UTC)[reply]
Good old Alt+Tab? --Ouro (blah blah) 20:15, 17 March 2023 (UTC)[reply]
In my X config, I set it to ignore first click on an inactive window. I also set it so if I launch a program and then click on a screen, the program automatically launches on the screen I clicked on. There are usually configuation settings for just about everything you want. The trick is learning enough about the settings to find and set what you need to set. 97.82.165.112 (talk) 21:23, 17 March 2023 (UTC)[reply]
Just some thoughts:
The window manager is responsible for making windows active or inactive, although applications can ask it to activate windows. So if you click on some window to activate it, the window manager handles that click. The application is responsible for handling clicks on buttons or other active elements. The application doesn't know about mouse operations on inactive (out of focus) windows, as the window manager never passes those to the application. The window manager doesn't know about the contents of the window, like what button is where. It only passes the coordinates of the cursor, relative to the corner of the window, to the application controlling the active window.
A mouse click consists of two events: a press and a release. If the press is used to activate a window, the release can be passed on to the application. It's up to the application to decide whether a button or other element can be activated with just a release. A window manager could also use the press to activate a window, but at the same time forward that press to the application controlling that window. The window manager may be configurable in that aspect. But whether the window manager forwards this activating press event to the application cannot depend on what button is under the cursor, as the window manager doesn't know. You may want to look into the configuration of your window manager.
I normally shift focus to windows (activate them) by hovering the mouse over them, no click required. A click is only needed to raise the window over other windows. Most Linux window managers have that option. Most of the time I've only one window per workspace, so I switch window by switching workspace, which can be done by keyboard. As workspaces are in a 3×5 planar layout, I need at most 3 key presses with arrow keys, or 1 with ctrl+Fx, to go to any other workspace. On a linear layout, like you get with alt+tab switching, you may need up to 14 presses if you have 15 windows (7 if you can also move back). PiusImpavidus (talk) 11:12, 18 March 2023 (UTC)[reply]
Microsoft Windows has or had a mode in which the active window was the one the cursor was in. No need to click. I liked this and wish macOS had a similar mode.  --Lambiam 11:18, 18 March 2023 (UTC)[reply]
@Lambiam:
A screenshot of MS Windows' background application window responding to a mouse event (hover).
This: "The application doesn't know about mouse operations on inactive (out of focus) windows" seems incomplete, or not precise enough. The image shows a window of an internet browser, which responds to a mouse event (the cursor hovering over a hyper-link) with a tool-tip popping, while the window remains inactive (background), partially hidden behind an active (foreground) MS Teams' window. The visible response suggests the background window knows about the mouse operation and actively handles it. --CiaPan (talk) 12:36, 20 March 2023 (UTC)[reply]
I was not the one who wrote this.  --Lambiam 12:58, 20 March 2023 (UTC)[reply]
The application knows that there was an event triggered and responded to the event. The window manager triggered the event based on watching the mouse movement. The application doesn't know what a mouse is or what mouse movement it. It subscribes to specific event types that the window manager can trigger and then does something when those events are triggered. So, you can use another program to artificially trigger window events and automate most programs because the applications don't know anything more than an event was triggered. 97.82.165.112 (talk) 19:07, 20 March 2023 (UTC)[reply]