GNOME Bugzilla – Bug 788644
Feature Request: Make tandem raise/lower optional
Last modified: 2021-07-05 13:51:47 UTC
A recent commit added this feature: window: Raise and lower tile match in tandem When a pair of tiled windows are grouped together, they are treated as parts of a whole and interacting with one affects the other. Following the idea that sibling tiled windows are treated as part of the same group, they should also be raised and lowered together. I'd like to ask for this to be optional, as in practice it ends up more annoying than useful. (For example, the way it selects a match is prone to accidentally grouping unrelated windows just because they're next to each other in the z-order...)
*** Bug 788755 has been marked as a duplicate of this bug. ***
*** Bug 788846 has been marked as a duplicate of this bug. ***
Yeah, I don't think this feature will be helpful, if e.g. we have a pair of tiled terminals, but then want to have a browser on one side and type in the other terminal without covering it. Or multiple pairs of tiled terminals, copying code between them... or etc. I see the above bug already mentioned the former case; clearly, it's not going to be a rare scenario, and this presumptive tandem raising is going to be very unhelpful to such users.
Having this feature as implemented and getting the tiled+untiled layout is much more painful than manually raising two tiled windows: Now to have e.g a focused left-tiled window and an untiled window visible to the right, the user has to untile every single right-tiled window, otherwise they are brought to the top of the RHS above the untiled window. Without this "raise in tandem" feature, it's only a extra action to manually raise the other tiled window. It's also not obvious at all why the last-focused window is disappearing when switching to the tiled window, until the user realises the connection with tiled windows on the other half of the screen.
This "feature" is pretty confusing. I can't see why and when windows are grouped together and regrouping windows is hard. I also can't see how many groups are there right now. Also this makes the work with tiled and untiled windows pretty hard. Some applications have a large window and a minimum window size and so they can't be grouped together since they can't be tiled. The only solution is to untile every window. Having two applications / windows behave like one application / window does not match with all other window management functions in GNOME. The overall behaviour is neither expected nor obvious. Please make it optional.
*** Bug 790322 has been marked as a duplicate of this bug. ***
I agree with the arguments that are brought up by the people above. When I initially installed GNOME 3.26 I noticed it once or twice, thinking that it was a bug. When looking into it some more I couldn't figure out what was happening, due to there being no visual feedback whatsoever when two windows are grouped together. I've never seen a system (whether that'd be GNOME, KDE, XFCE, MS Windows, anything) manage windows in this manner and I personally find it highly confusing, since you're not expecting it to happen. I can't imagine a lot of people not being confused by it to be honest. I would highly appreciate an option to enable/disable this behaviour, and in order to avoid confusion I would also disable this behaviour by default.
Also agree that this should be reverted. The tiled windows also aren't grouped in GNOME Shell's overview which is inconsistent and confusing. I'm also against an option as I think this is more fitted for an extension.
(In reply to Jan Niklas Hasse from comment #8) > Also agree that this should be reverted. The tiled windows also aren't > grouped in GNOME Shell's overview which is inconsistent and confusing. Of course an alternative for fixing the inconsistency is respecting the grouping in the overview as well.
The difference is that this alternative doesn't have a patch ready.
And it doesn't fix any of the other issues with the behaviour either. It's a nice idea in theory for some *specific* use-cases, but badly thought through and breaks a lot of other use cases. If the feature got to the point of something like: * **selectably** grouping windows (e.g. in the window menu of one of two tiled upmost windows -> "group with window on left/right", plus an "ungroup" option) * a visual indication in *all of* the overview, when the windows are topmost, and in Alt-Tab then it would be a nice feature with no "what the hell" behaviour and/or confusion. Until then, it should be reverted, to be blunt.
And also, those specific use cases are almost certainly below the threshold of wide usefulness to be a standard part of Shell, if the bar set until now for acceptance/rejection of additional features is used as a reference - this is extension stuff by that measure.
(In reply to Florian Müllner from comment #9) > (In reply to Jan Niklas Hasse from comment #8) > > Also agree that this should be reverted. The tiled windows also aren't > > grouped in GNOME Shell's overview which is inconsistent and confusing. > > Of course an alternative for fixing the inconsistency is respecting the > grouping in the overview as well. In the overview, in Alt+Tab, in the classic taskbar, and so on? But this minor inconsistency is not why I filed the original request/report. I agree that the grouping is useful in quite a few cases. But when someone is trying to have *independent* windows on both sides, the WM just ends up actively *working against the user*, which is worse than not having grouping at all... (Here's how it could be reproduced: 1. I have a left-tiled terminal window. 2. I open the browser window and start reading about something. 3. I open a new terminal window #3 to check out something related to the browser contents. (E.g. try out some command from a manual.) 4. I right-tile that terminal window as it's a very convenient shortcut for positioning it. 5. I Alt+tab back to the browser to check another page. As a result, the two terminals become right next to each other in the z-order. 6. I Alt+tab back to the terminal window #3, and the grouping heuristics bring up the completely unrelated terminal #1 alongside it. Believe it or not, this situation keeps happening often. Am I using tiling "not as designed"? Should I use maximize-vertically instead? Should I just return to untiled windows and resize them by hand? I could do that, but ehh.) All that said, now I have some vague memories of ...not sure what environment, Windows perhaps? or Plasma? having a round "lock" button in the middle, which would link the two tiled windows together without relying on heuristics. Clicking it again would unpin them. (No, I'm not asking for such a feature, just seems like a possible approach.)
Any update on this? Would be great if it could be fixed in 3.26.3.
(In reply to Jan Niklas Hasse from comment #14) > Any update on this? Yes - see and read the previous comments in this very task. > Would be great if it could be fixed in 3.26.3. There are no plans for a GNOME 3.26.3 release in the GNOME 3.26 schedule (but module maintainers are free to release additional updates).
> Yes - see and read the previous comments in this very task. task = bug report? I'm not sure what you mean.
Yes. task, ticket, bug report, enhancement request, issue. :)
Okay, then which comment do you mean in particular? I'm missing the developers stance on this (e.g. what you or Florian think about the questions asked or the points raised in https://bugzilla.gnome.org/show_bug.cgi?id=788644#c13).
Any comment, because all those comments are updates. If you have a more specific question than just after "updates", feel free to ask it. But all and any updates can be seen in this very task (there are no other places that receive updates about this topic).
Why not revert this feature and bring it back, after the inconsistencies have been taken care of and the overall decision if this is wanted at all has been considered more thoroughly?
*** Bug 790622 has been marked as a duplicate of this bug. ***
Obviously, the request for an "update" didn't just mean any comments: it meant whether a developer has yet expressed an indication of what is going to happen. The answer is not yet, but as the multiplying duplicates indicate, the issue is known. That also indicates that asking for an update isn't likely to cause any reaction; if there was one, a dev would post it. It's very likely that a solution will be worked out, given time and consensus among those who need to decide it. The rest is just noise at this point.
(In reply to Daniel Boles from comment #22) > It's very likely > that a solution will be worked out, given time and consensus among those who > need to decide it. I think this discussion should have happened *before* the commit. Now, any stalling tactics will benefit those who like the new feature, so there's no incentive for them to get the ball rolling.
*** Bug 791152 has been marked as a duplicate of this bug. ***
*** Bug 791541 has been marked as a duplicate of this bug. ***
Oh wow, time to stop using GNOME then. Been using it as my only system since 3.0 but this "feature" breaks how I've worked with it now for the last 5 or so years. Way to really cater to your senior users. Been through this kind of treatment before - lots of bug reports but it's like talking to a wall. Remember that sound volume bug which could be solved with a 1 line change? Yeah, it was reported some 10 years ago and is still ignored. Way to go GNOME team, you sure know how to satisfy your users.
(In reply to Alex Hultman from comment #26) > Oh wow, time to stop using GNOME then. > [...] > Way to go GNOME team, you sure know how to satisfy your users. For what it's worth, we had a meeting a fortnight ago where we agreed to revert the change for the next stable release. There are still some design questions, which is why we scheduled another meeting (due tomorrow actually). But then we get entitled comments like that, which seriously make you reconsider listening to anybody. And well, as according to your own comment you don't use GNOME anymore anyway, why should we even care? *claps hands*
> we agreed to revert the change for the next stable release. Wow, you're so fast. So much wow. *claps hands*
> For what it's worth, we had a meeting a fortnight ago where we agreed to revert the change for the next stable release. Disgruntled other comments aside, a message on this bug saying as much at that point would have helped a lot.
Well I'm sorry but there is a clear pattern here repeated over and over, where you never seem to get where you aim for. Every release is like yet another alpha of yet another major design change. It never really gets to beta or stable, it's always a rolling alpha. You never follow your ideas through. Heck, if we could have a stable and polished GNOME 3.0 with all glitches, timing bugs, text wrapping issues, overview bugs and glitches, etc just fixed and polished I would use that over any 3.26 all day long. Every release fixes 5 and introduces 5 new bugs, you always think "oh but NEXT release will have THIS bug fixed and THEN it will be polished" but instead you completely toss everything around essentially creating a completely new alpha of a completely new design.
(In reply to Jan Niklas Hasse from comment #28) > > we agreed to revert the change for the next stable release. > > Wow, you're so fast. So much wow. OK, let's not revert anything for 3.26.3 then.
Florian I think if this bug devolves into bickering no-one benefits. I don't think that sarcastic comments like Jan's last one warrant much attention.
Alex Hultman, Jan Niklas Hasse: Regarding tone, please read and follow https://wiki.gnome.org/Foundation/CodeOfConduct if you'd like to continue to be active in GNOME Bugzilla. Thanks for keeping this a respectful place.
Do you think that Florian's comments are respectful and considerate?
Comments in Bugzilla are chronologically ordered. Anyone can see who started to ignore our CoC and what are reactions to tone. Consider this a final warning.
Not sure if I understand you correctly, so please correct me if I'm wrong: You mean that comment #27 wasn't the first to ignore the CoC, but #26? Why am I being called out then when my CoC-ignoring-comment was #28, so also not the one who started it?
Tone. You can find that unfair or not, and you can interpret terms and words differently or not. In any case, it's unrelated to making the tandem action optional and could be discussed in a different place if you feel such a need. Not here. Thanks.
*** Bug 792368 has been marked as a duplicate of this bug. ***
*** Bug 792225 has been marked as a duplicate of this bug. ***
Coming back to the issue: Is anyone of you aware of a patch or shell extension that disables the tandem feature? Kind regards and thank you very much for your time and efforts invested in GNOME!
(In reply to e.h.juerrens+gnome from comment #40) > Coming back to the issue: > Is anyone of you aware of a patch Yes, https://gitlab.gnome.org/GNOME/mutter/commit/415584344a5d4b5 on the gnome-3-26 branch :-)
So, can't this be marked as resolved fixed?
(In reply to Daniel Boles from comment #42) > So, can't this be marked as resolved fixed? Probably not yet – it's reverted for 3.26 but not master. (Not entirely sure why. I know there are plans to re-do it in a better way, but it seems too late for those to make it to 3.28...)
Yikes. Thanks for the info! I didn't realise "on the gnome-3-36 branch" meant it wasn't on master. So if it's not picked there too, we all get to go through this same process a 2nd time... :D
Florian, have there been any changes to the 3.26 behaviour that would justify this not being reverted in 3.28 as well? If not, can this be reverted with a freeze exception before 3.28 is released (which is presumably on ~Monday)?
(In reply to Stephen from comment #45) > If not, can this be reverted with a freeze exception before 3.28 is released > (which is presumably on ~Monday)? Yup, that's what George and me agreed on yesterday, and I just sent out the freeze break request.
I just updated to Gnome 3.28 today, and tandem raise/lower is gone, just like how it was gone in 3.26 recently. Can this bug be closed or is there something left to do? Either way, thanks for taking care of this!
For anyone that misses it, I created an extension restoring the tandem raise behaviour: https://extensions.gnome.org/extension/1506/tandem-raise/
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.