PaperWM
PaperWM copied to clipboard
paperwm
Apps not using full height in workspaces without top bar
Is your feature request related to a problem? Please describe. I hide the top bar on all workspaces except one, and when switching between workspaces, apps in workspaces where the top bar is hidden get resized as if the top bar is there so they are not taking the maximum height.
Describe the solution you'd like Apps in workspaces without the top bar should not take the bar height into consideration.
Additional context
https://github.com/paperwm/PaperWM/assets/97781843/fb3e56f4-5479-4b5f-a6e1-957fc7e110d4
Edit: Even if the bar is hidden in all workspaces, it still happens because the bar is shown while switching workspaces, I tried disabling the bar on the desktop with the Just perfection extension and apps still have the full height after switching between workspaces, So maybe an option to not show the top bar while switching workspaces would fix the issue?
Thanks for reporting @Mohs9n, definite bug. I can reproduce so will try looking into this when I can.
Jay.
@jtaala that might actually also be fixed by my PR #707 ~(but I have to retest that again)~ Edit: seems to be fixed at least for the case where there is no topbar on the second monitor, which is not exactly the same issue since here it is all on the same monitor.
@Mohs9n how exactly are you hiding the topbar on all workspaces except one? We might need to adapt the check a bit to also check if the topbar is completely hidden (instead of just the position).
how exactly are you hiding the topbar on all workspaces except one?
So, this is input is actually a relic from the time when we had a topbar that followed focus. But it still works (kind of).
Ah never used that :D I can also fix this in #707 if you want since I'm changing that code anyway (and in that PR I think I currently actually broke that functionality^^).
Nice one! Sounds good - I had a quick look at the issue, and would have to do with fixTopbar method and the update/showTopBar methods (which you're working on anyway).
Will leave to you. Note, the space at top etc. is generally caused by layout's workArea calculation. Wit the topbar approaches, we're influencing it by changing PanelBox.height etc.
We could also do that logic more explicitly in layout, e.g. like I did for the window position bar, e.g. https://github.com/paperwm/PaperWM/blob/release/tiling.js#L607-L615
Anyways, that TopBar stuff def needed a good refactor and improvement.
Thanks @Lythenas.
Is it possible to revisit this since https://github.com/paperwm/PaperWM/pull/707 won't be finished in the near future? Or is the Fullscreen Avoider compatibility issue related to this bug? if it is, then never mind!
Hey @cbmiller2610 and others,
I've done some work on this - it was quite a complicated refactor/rewrite and it is possible I've missed some corner cases with this behaviour.
Can you please test this PR?
git fetch --all
git checkout fix-709-notopbar-layout-height
./install.sh
then logout / login.
I installed the new branch this morning, currently looks like it's working as intended! PaperWM is my daily driver, I'll continue to use it and see if I find any edge cases.
@jtaala one issue I didn't notice on the last PaperWM version: now when you bring windows to scratch they get vertically resized, and some windows actually make vertical size go to zero (Kitty terminal). The Element Matrix client now gets resized very small, and I definitely never noticed it before (I often leave it open on my scratch layer). If this is not related, let me know if I should open a separate issue!
https://github.com/paperwm/PaperWM/assets/7013753/4a8e48f8-2112-4625-8ab4-9c707c3cd79b
Another bit of feedback: hiding the top bar needs to also disable the Window Position Bar for those workspaces in order for the TopBar space to go away, (see screenshot with Window Position Bar Enabled)
@jtaala one issue I didn't notice on the last PaperWM version: now when you bring windows to scratch they get vertically resized, and some windows actually make vertical size go to zero (Kitty terminal). The Element Matrix client now gets resized very small, and I definitely never noticed it before (I often leave it open on my scratch layer). If this is not related, let me know if I should open a separate issue!
Screencast.from.2024-06-14.08-57-44.trimmed.mp4
Good pickup. Does this happen in latest release or just on this branch?
now when you bring windows to scratch they get vertically resized
Thanks @cbmiller2610, have now fixed that (pull latest on the PR branch).
Another bit of feedback: hiding the top bar needs to also disable the Window Position Bar for those workspaces in order for the TopBar space to go away, (see screenshot with Window Position Bar Enabled)
That makes sense.
I can see that some users may want to disable window position for certain workspaces (like we do topbar) - and even (for some reason) disabled topbar but have window position bar?
Thoughts on adding a disable Window Position Bar under the Hide top bar option in workspaces and have them selectable (so in your case you would select both options).
That's fair, I guess it makes sense some users would still want the visual hint despite no top bar. The idea of grouping the toggles together in Workspaces is a great idea, and it adds an additional customization (since right now the Window Position Bar can only be enabled/disabled globally). So I'd think you'd want to remove the universal toggle from under "Settings" as well, and just have the per-workspace toggles under Workspaces.
now when you bring windows to scratch they get vertically resized
Thanks @cbmiller2610, have now fixed that (pull latest on the PR branch).
Looks like that fixed the issue! Awesome
So I'd think you'd want to remove the universal toggle from under "Settings" as well, and just have the per-workspace toggles under Workspaces.
No, we wouldn't remove a global setting for this. Think of the workspace settings as an override for that specific space. The wording is important here, it'll be "Hide Position Bar".
This works the same way as the topbar setting. There's actually a hidden dconf setting default-show-topbar. That is, we set a global setting (on/off), then we allow users to override that setting on a per-workspace case - that is, to "hide" it if the global setting is on.
Otherwise, users would have to set it for each workspace (which would suck in the case of dynamic workspaces).
@cbmiller2610 - pull the latest. I've implemented the per workspace overriding for position bar.
I think I got all the corner-cases for this. Let me know if you run into issues.
@jtaala I think this is probably the last thing, there is a case like is shown below:
Global Window Position Bar : toggled ON Workspace Specific Hide Gnome Top Bar: toggled OFF Workspace Specific Hide Window Position Bar: Toggled ON
This results in the Window Position Bar remaining active on that workspace, despite the toggle.
Ah, it also seems that the Window Position Bar hiding isn't quite working in general. I have TopBar and Window Position Bar set to hidden on Workspaces 3,4,5, and the Window Position Bar keeps showing up again. It will go away if you bring up the settings and turn the toggles off and on, but as soon as you start working with the windows it will show up again!
Ah, it also seems that the Window Position Bar hiding isn't quite working in general. I have TopBar and Window Position Bar set to hidden on Workspaces 3,4,5, and the Window Position Bar keeps showing up again. It will go away if you bring up the settings and turn the toggles off and on, but as soon as you start working with the windows it will show up again!
hmmm - seems there's still some bugs here. Although, I'm not seeing this (trying to reproduce your setup). Can you confirm the commit you're on? (it should be 210a37dd724e658b52a21aaaefe09b47ff1feda1).
Lastly, can you take a pic of the workspaces shown on your setup, e.g. like:
Cheers.
@jtaala Finally got back around to looking at this, and now everything is working fine. Looking back, I suspect I may have gotten distracted and not logged out/in after git pull... apologies for the confusion. I'll keep an eye out, but it looks good to me!
And yes, I'm on the latest:
commit 210a37dd724e658b52a21aaaefe09b47ff1feda1 (HEAD -> fix-709-notopbar-layout-height, origin/fix-709-notopbar-layout-height) Author: Jay Ta'ala [email protected] Date: Sat Jun 15 21:03:43 2024 +1000
Replaced (where appropriate), instances of `add_child` with checked
substitutes.
Thanks @cbmiller2610 - just updated the branch a little (small reversion of some changes).
I noticed once during workspace (sequence) switching that releasing the keybind didn't bring it out switching mode (had to hit escape to exit it) - but I can't reproduce this now. Let me know if you see this too btw.
P.S. I feel we should add some keybinds for these (toggle hiding topbar / position bar) for a workspace. I reckon it might be useful to hide/unhide these elements for a workspace quickly (e.g. when I don't want see the topbar/time for example when I need to focus on something).
That would be great! What about: Super+h or Super+g: Toggle Gnome TopBar Super+p: Toggle Window Position Bar
Currently Super+h is a bit weird in PaperWM anyways IMO, since it hides windows in the typical gnome way (which doesn't seem to fit the PaperWM paradigm I've seen so far). When you hide a window using Super+h you have to recall it using the same keybinds you would use for scratch windows. I never use this, and instead almost always just throw the window I want to hide onto another workspace, or into scratch.
Super+p is something related to multi monitor setups, and also doesn't even seem to be something people appreciate in Gnome anyways... https://askubuntu.com/questions/1487924/what-is-mapped-to-superp
Super+h or Super+g: Toggle Gnome TopBar Super+p: Toggle Window Position Bar
See latest commit.
Well, good logical keybinds are getting harder to find in PaperWM. To ease this, I've chosen one default, simple keybind (Ctrl+Super+b) which will toggle both topbar and position bar (together) and then allow users to change that and to set the others as they like:
Currently Super+h is a bit weird in PaperWM anyways IMO, since it hides windows in the typical gnome way (which doesn't seem to fit the PaperWM paradigm I've seen so far). When you hide a window using Super+h you have to recall it using the same keybinds you would use for scratch windows. I never use this, and instead almost always just throw the window I want to hide onto another workspace, or into scratch.
Just a note here - super+h is just normal gnome window hide, and you recall it using the normal gnome approaches (e.g. you can see the hidden windows in gnome overview).
We wouldn't overwrite that in default PaperWM as it's used by others and works fine in PaperWM.
Also wouldn't overwrite super+p for similar reasons - it's used and works fine in PaperWM (i.e. I use super+p all the time for monitor/display changing).
@jtaala Wow the keybindings make this really awesome. It's like instant focus mode with the TopBar off, and when you need something it seems so much nicer to just unhide the TopBar rather than going to the Gnome overview. This is a great addition to PaperWM!