#7630 closed bug (fixed)
Sent back windows won't rise again
Reported by: | humdinger | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Servers/app_server | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #8158, #9156 | |
Platform: | All |
Description
I think I found a window behaviour that has changed when compared to earlier revisions, though I have no idea when...
This is R1/alpha3, hrev41843.
Mouse settings: Click to focus and raise, Accept first click.
This is as expected:
- Have two windows open (e.g. web+ and vision), overlapping a bit.
- The top one is active (yellow tab).
- Click anywhere into the bottom one, it's raised, becoming active.
This is unexpected:
- Have two windows open (e.g. web+ and vision), overlapping a bit.
- The top one is active (yellow tab).
- Right-click its tab, it's sent to back. But apparently still active. Q: Is this correct? Might be. Maybe the now top one should become automatically active. I don't know... But carry on...
- Click anywhere into the bottom one you have just sent back, -> it's not raised. I think it should.
Only when clicking onto its tab or border the window rises again. It should come up if clicked anywhere.
So, while you can alternate between overlapping windows by bringing the lower one to front by simply left-clicking anywhere into the lower window, this won't work anymore when you have sent one window to the back using a right-click on tab/border (or by using CTRL+ALT+rightclick).
For Tracker window, it works as expected.
#6420 had a related issue, but not the same. If that helps...
Change History (13)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Either you didn't follow my description exactly, or something very strange is happening that produces different behaviour in the same revision. Nobody able to reproduce?
follow-up: 5 comment:3 by , 13 years ago
follow-up: 6 comment:4 by , 13 years ago
Since I can't provide a solution, all I can say is that I like how the Desktop now grabs the focus, but still find the behaviour described in this ticket quite annoying. I'm not really sure what I'd pick if I had to weigh the new feature vs. the new bug...
comment:5 by , 13 years ago
Replying to axeld:
See #7280, and hrev41264. The behaviour you observe is just a side effect of that - opinions welcome :-)
As this is currently implemented, it works great. Its just not very obvious why the window will hide at first. Now that I know how to use it. Its great. rick click put out of focus, left click to focus. so simple I wonder why it has never been implemented before as part of another OS ??
I give it a big thumbs up, beats dealing with minimizing etc. Actually kind of makes the deskbar a bit redundant in reality.
follow-up: 7 comment:6 by , 13 years ago
Replying to humdinger:
Since I can't provide a solution, all I can say is that I like how the Desktop now grabs the focus, but still find the behaviour described in this ticket quite annoying. I'm not really sure what I'd pick if I had to weigh the new feature vs. the new bug...
A side effect doesn't mean either or - the behaviour can be altered to something that you may like more :-)
The question is just: how? The easiest solution would be to give the actual front window focus when you send a window to the back, but it would also be possible to move a window to front that already has focus on click (that click would always make it through to the window, though, so maybe the better solution is to have what used to happen in this case).
comment:7 by , 13 years ago
Replying to axeld:
A side effect doesn't mean either or - the behaviour can be altered to something that you may like more :-)
Nice! I'd hate to have the Desktop lose focus again. <wink> ;)
The question is just: how? The easiest solution would be to give the actual front window focus when you send a window to the back, but it would also be possible to move a window to front that already has focus on click (that click would always make it through to the window, though, so maybe the better solution is to have what used to happen in this case).
Here's what I think would be best when a window is sent to back via right-click:
- with the default "Click to focus and raise": focus the now top window
If a window gets focus and is raised on a click, a user can expect that a window loses focus when he sends it to the back.
- with "Click to focus": keep the focus on the sent-to-back window
If a window just gets focus on a click and isn't raised, a user can expect that a window still has focus when it's sent to the back.
- Focus follows mouse isn't concerned of this issue.
comment:8 by , 13 years ago
Version: | R1/alpha3 → R1/Development |
---|
R1 Alpha 3 has not yet been released. This was with an R1 Alpha 3 Release Candidate image.
comment:9 by , 13 years ago
Blocking: | 8158 added |
---|
comment:10 by , 12 years ago
Blocking: | 9156 added |
---|
comment:11 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in hrev45252, please tell if you aren't satisfied with this solution :-)
comment:12 by , 12 years ago
Thank you, thank you, thank you[[BR]] You'd think that after almost 2 years one would get used to that usability mishap, but I didn't. Finally one big annoyance is gone. I'm actually misting up a bit here...
Now, if Oliver could revert his CMD<->CTRL + cursor-wordwise-jumping blunder... :P
comment:13 by , 12 years ago
Yeah, sorry it took me so long - you could have cornered me at BeGeistert, though :-)
Left click typically raises a window.
Right click drops the windows back, left click raises it. Works fine for me on A3RC's