Closed rhythmthief closed 6 years ago
Thanks a lot for reporting this! I think I saw the same issue reported for Pixel Saver. I will try to look into it. As usual, patches welcome if anyone finds a fix.
Instead of fixing the described issue, isn't it better to ignore snapped windows from being undecorated?
If I have two snapped windows (one left, the other right) + the fix for this bug, I would always guess which one is currently on focus and hope not to close the wrong one.
@tradespite that's a good point. My guess is many people will complain if we remove this, but I could see making this optional. What do you think?
@franglais125 yes, of course, only optional through a feature toggle :)
But for the undecorated version for snapped windows, I still think it would be a bad behavior to show the control buttons.
Some information: we could do this by looking for the property .tiled
in the css node.
Source: https://developer.gnome.org/gtk3/stable/GtkWindow.html
@rhythmthief @tradespite any one of mind testing https://github.com/franglais125/no-title-bar/tree/vertical_windows?
I included two options (for buttons and app menu) to toggle this. I want to make sure it works, but also that it doesn't introduce regressions for people who don't want this!
Thanks in advance!
@franglais125 working fine for me! There is now a minor quirk where snapping a single window to the side and focusing some other window (which is not snapped) leads to a situation where you have controls for the former and an app menu for the latter, but honestly it's so small I don't think it's going to bother anyone too much. Thanks for everything!
@rhythmthief Thanks a lot for the quick feedback!
leads to a situation where you have controls for the former and an app menu for the latter
Isn't this the case already for maximized windows as well? For instance, a maximized terminal, and a Nautilus window (non-maximized). App-menu belongs to Nautilus, while the controls belong to the terminal.
Since the beginning (when I used Pixel Saver), I found this a bit confusing, but then I realized it makes sense if we think of the top bar as being the title bar of the maximized app (except for the app-menu). I don't think we can workaround this though. Removing the buttons for snapped (and maximized) windows will break the experience of users who have bee using Pixel Saver for years.
Personally, I don't really use the buttons (I usually use the keyboard), so it didn't bother me.
But anyway, it is working, right? If I don't find any regressions (I'll also wait for @tradespite ), I'll merge this to master and release a new version soon.
@franglais125 Yeah, the way it works right now actually makes a lot of sense, just threw me off for a moment. Doesn't look like there are any regressions either, so I think it's good to go. Thanks!
I tested it and I found a strange behaviour, maybe someone else could test it: If I snapped a window via mouse to the right side, a black decoration is shown. (no other window is maximized) Snapping a window via keyboard shortcut (left and right) works fine.
These are my settings:
@franglais125
Since the beginning (when I used Pixel Saver), I found this a bit confusing, but then I realized it makes sense if we think of the top bar as being the title bar of the maximized app (except for the app-menu). I don't think we can workaround this though. Removing the buttons for snapped (and maximized) windows will break the experience of users who have bee using Pixel Saver for years.
Yes, I also think it's correct, that the buttons are shown for the maximized window and the shown app menu is 'wrong'. But I have also no idea how to bypass this.
@tradespite Is this snapping problem present only with the new branch? Or was it like that before as well?
Two more questions: what program is that, and what Gnome version are you running?
In v5 I can reproduce it too. So it isn't a bug from the new branch.
Gnome Version 3.24.2 Application: Nemo, but I can reproduce it also with Firefox
And now I see this isn't always...
@tradespite Yeah, I've seen this happen as well. I don't think I can fix it, I'm sure it has something to do with the program miscalculating the geometry, due to the missing title bar. While this is a valid thing (removing the title bar), it's not very common, and I guess it is not very well tested upstream.
In my case, the worst offenders are Firefox and Rhythmbox. Anyway, thanks for the clarification!
I'll merge this soon then.
I included this in master. I'll see if I can fix a few more things, and then I'll publish to e.g.o.
You can run this from git obviously for the time being!
Thanks a lot both of you for the feedback!
@tradespite how consistent is it in your case? I couldn't reproduce it with either nautilus or Firefox, or any other application, really.
@rhythmthief sometimes I can reproduce it 5 times in a row... sometimes not... Maybe it's a problem with another extension installed on my system.
Snapping a window to either side of the screen removes the title bar, as if the window has been maximized, but does not seem to invoke the window control buttons (same for having two windows snapped at once).