-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiple monitors: strange behavior #700
Comments
Thanks @stefangweichinger. Not sure I'm understanding what you're describing. Can you please take a screen capture/video (even if on your phone etc.). and post it here? Re Scratch and dragging: it depends when you release the dragged window - if you're by a tiling boundary, there will be visual indicators where you can drop the window (and it will be tiled): Kooha-2023-11-17-07-58-52.mp4However, if you drop NOT in a tiling boundary the window will be added to the Scratch layer: Kooha-2023-11-17-07-59-19.mp4 |
@jtaala thanks for the infos and the videos, understood. I will try to come up with a video asap. |
@jtaala question: are tiled windows and "scratch windows" somehow displayed differently? Could I have different edges, for example? I will check later on my desktop ... it's not always clear to me if a window is tiled or a scratch window (which makes it hard to understand that "flipping" behavior I see). But maybe I can reproduce and provide the video ... and you can make sense of it. |
It should be very apparent - tiled windows are tiled and take the full vertical height. Scratch windows are floating and look like normal Gnome windows (when PaperWM is not activated). Note: generally scratched windows |
On my desktop sometimes scratched windows also are nearly full height ... so that confuses me. But I will check again when I am back at that machine. thanks. Currently on the laptop: happy with PaperWM here ;-)
"are used" or "aren't used very much" ? You write "hardly used at all" ... so I assume the second ... |
Yes, the second (aren't used very much). How are you scratching windows? with the keybinds? |
Also note this from https://github.com/paperwm/PaperWM#scratch-layer (which sometimes confuses new players):
Meaning if you have scratched window selected/active when you open another application - it will open also in the scratch layer. |
Ah, that might help, yes. I will think of this next time using my desktop. I will report back as soon as I can reproduce my issues. Have a nice weekend ... |
maybe my issues were related to my newbie status. I will see tomorrow when I am using my desktop for a longer period of time. Or did the latest upgrades maybe already help? thanks. |
Let me ask: should the indicators be there all the time? For any dragged window? Or are the indicators only shown around tiled windows? I sometimes see no indicators, the dragged windows can't be dropped into "tiled position". thanks. |
The scratch layer and the tiled layer are completely separate. Windows in the scratch layer don't have a PaperWM window border (only the default gnome one), they don't interact with other windows in any way, they can be dragged like normal windows (as if PaperWM was not there) and can therefore not be tiled by dragging, they are independent of the workspaces, so they are visible on all workspaces (of the monitor). I mostly use the scratch layer for windows that I don't normally need to see or want to manually navigate to (e.g. my VPN window, I only need this once on bootup but it needs to stay open) and windows that don't work well in PaperWMs tiling (e.g. the Android Emulator because it has a second window with the controls that follows the main window). I hope this helps. I believe we could explain this a bit better in the readme, I haven't looked at it in a while. But most of the information should be there in some form. |
Drop indicators are only shown when first dragging a tiled window around. Once a window is actually on the scratch layer - indicators are not shown. To tile a scratched window (window that's already scratched), select it and use the designated PaperWM keybind: or use the Gnome window menu "Scratch" option, e.g. see this comment: #661 (comment) Indicators are meant to allow to move a tiled window with the mouse (although, tbh, it's much easier to use PaperWM keybinds for this purpose). |
This is a good point - it might actually be handy / neat to have the indicators show up even for already scratched windows? |
If we are talking about the window borders then yes, sometimes it is hard to tell which of the scratch windows is focused. The default gnome active/inactive is very subtle. So I think this would at least be worth trying out. But I think we should not allow dragging a scratch window into a tiled position. Because that would probably make dragging it around without tiling very hard and annoying. |
My main issue as a new user might be, that on my desktop I seem to create scratched windows somehow without really noticing. And as I don't really see the difference it is hard to understand the different behavior of windows. I tend to think that it might be helpful to add some "learning mode" toggle, that enables drawing tiled and scratched windows with different borders maybe. I understand that dragging scratched windows to tiled position is maybe problematic. On the other hand I think it should be possible to "convert" a scratched window to a tiled window with some mouse-centered action also. At least for me it is still not easy to toggle that (having to check some handwritten note for the shortcut ... ). This might become easier after some more learning. Additional: yesterday I noticed some of that random(?) switching of windows on one monitor while moving the mouse between the 2 screens. I can't really describe ... at least: Thunderbird, Chrome, Tilix involved. I assume it has to do with 2+ chrome windows opened on separate monitors. Something like that. Then one chrome window switches into the background when mouse is moved over to the other screen. Can't tell exactly right now. And as far as I understand this is not intended behavior even with scratched windows displayed, right? thanks all |
Doesn't sound like it - In order to fix this we'll need some reproduce steps. @Lythenas may have noticed this behaviour since he uses multi-monitors I believe. |
This already exists (see #661 (comment)) - although if a window doesn't show default gnome window decorations can make it a bit harder). I'm not personally interested in adding another way to tile a scratch window (we already have keyboard and gnome decoration menu). However, this is open-source, so I would accept a PR that implements this. |
How does this happen? I'm guessing that you have a scratch window selected / active and open another window (which will then also be scratched): e.g. from the README.md:
If this is the root cause of scratching a window without noticing - I'd be open to changing this behaviour so that new windows are tiled (unless there's a winprop to scratch it). |
I will try to reproduce. Yesterday there were too many sensitive informations in all the windows, I couldn't share that as a video ;-) |
Yes, this might be my problem (of understanding): I will keep that in mind and see if it explains things better.
thanks for the offer. this afternoon I will be afk (from my office pc with the 2 monitors) so it will take a while before I can do more of my tests. greetings ... |
Sometimes I also run into this behavior. Although not recently. I think the problem is that the window thinks it is on monitor 1 but is actually shown on monitor 2 so it will hide when you focus monitor 2 and there is no way to focus the window to correct the error. Sometimes using |
Right now I have the issue, that the top bar appears on one monitor when I move the mouse AWAY from that monitor. In the GNOME settings it is not set as primary ... so the top-bar stays enabled on the primary monitor (1) but disappears on the other monitor (2) as soon as the mouse leaves that monitor (2). Checked for other extensions, disabled "Compact Top Bar", no difference. There are scratched and tiled windows on each monitor right now. There is a chrome window on (2): as soon as I move it the behavior changes. I toggle between scratch and tiled and the top bar stays visible. |
… windows when a scratch window is selected) (#718) This PR changes several widow behaviours related to scratch windows. It seeks to make scratch windows more predictable (in how one scratches a window) and try to minimise instances of "accidentally/unexpectedly" scratching windows. Users (especially new users) seem to struggle with some of the behaviours for scratch windows. See some example comments here: - #680 (comment) - #700 (comment) - #700 (comment) On review, a couple of behaviours are rather unintuitive with scratch windows: 1. when a scratch window is selected, any new window opened will also be scratched. I understand the thought here, but this is rarely what's wanted (for me anyway) and often leads to confusion. This PR undoes this. New windows will be tiled (regardless of whether a scratch window is currently selected). 2. Dragging a window (with mouse) and NOT dropping on a target now re-tiles that window (previously it scratched that window). I've had two user reports in the last few weeks of this (reported as a bug). In any case, it seems the more intuitive option of for that window to be re-tiled: https://github.com/paperwm/PaperWM/assets/30424662/9c4a20d6-52e3-408f-9c0a-62ee0ceb6244
This PR changes several widow behaviours related to scratch windows. It seeks to make scratch windows more predictable (in how one scratches a window) and try to minimise instances of "accidentally/unexpectedly" scratching windows. Users (especially new users) seem to struggle with some of the behaviours for scratch windows. See some example comments here: - #680 (comment) - #700 (comment) - #700 (comment) On review, a couple of behaviours are rather unintuitive with scratch windows: 1. when a scratch window is selected, any new window opened will also be scratched. I understand the thought here, but this is rarely what's wanted (for me anyway) and often leads to confusion. This PR undoes this. New windows will be tiled (regardless of whether a scratch window is currently selected). 2. Dragging a window (with mouse) and NOT dropping on a target now re-tiles that window (previously it scratched that window). I've had two user reports in the last few weeks of this (reported as a bug). In any case, it seems the more intuitive option of for that window to be re-tiled: https://github.com/paperwm/PaperWM/assets/30424662/9c4a20d6-52e3-408f-9c0a-62ee0ceb6244
Let me add that I keep the extension up to date, and although I didn't yet find the time to really read the details about the latest changes ... I like the current behavior and face the described issues not that often anymore. Thanks for your ongoing work! |
I currently see this: having windows on both monitors, "Tilix" on one monitor, tiled. When I move the mouse pointer to the other monitor (no clicking) the tilix-window gets "zoomed out" as if to be shown in the overview. As soon as I move the mouse back to the monitor showing tilix it hops back to its correct full height size. This also happens when there is a second (chrome-)window open on that monitor: chrome stays full size, tilix switches between full and half height when I move the mouse between the monitors. That's a bit irritating. Might be a tilix-issue also? EDIT: the tilix-window also does that when it's maximized. Strange. |
@stefangweichinger this seems similar to the issue with wezterm #498 |
Yes, thanks! |
It's not exactly the original issue anymore and maybe we close this one as "messed up" ;-) My current itch to scratch: The overview shows the workspaces next to each other, while the shortcuts "win+pgup/pgdown" order them above/below each other. This messes with my mental map of things: what is where right now? The overview often shows many empty workspaces and that also seems wrong. Ah, I see an upgrade available while I look for extensions to turn off: will upgrade and re-check things |
Hey @stefangweichinger. So, PaperWM was always vertical workspaces (back when gnome was also vertical workspaces). It's switched it's overview to horiztontal. Just the way it is (I prefer vertical and don't really use the overview much).
This is from a gnome workspace paradigm clash (this one is much deeper) - see comment #389 (comment) for the reason why. It's basically due to Gnome's having a "one workspace across monitors" paradigm, which is not something we can change easily. PaperWM has a "one workspace per monitor" paradigm. The empty workspace is from Gnome thinking that "there's two monitors and we're showing a workspace... which spans monitors right...", which isn't true for PaperWM. |
Those options must be new in Gnome 46? Anyways, the left/right thing is interesting and also due to the difference Gnome / PaperWM takes with workspaces. In PaperWM, workspaces can be moved between monitors, so you can have a workspace 2 on monitor 1, and workspace 1 on monitor 2. In PaperWM, "move to right workspace" means numerically, e.g. if you're on workspace 1, it means move to workspace 2 (e.g. increment by one). Now, if workspace 2 is on monitor one... then it moves there. I really only work on features that I use - and instead use PaperWM's keybinds to move windows to other workspaces (mainly the take/drop windows functionality, e.g. #808 and #810 ), so I wouldn't change anything here - but would accept a PR if you or others want to work on that. |
@jtaala thanks for the feedback .. I will see if I can come up with some usage that works for me. I am no coder myself, so I can't provide any PRs here. |
Please do not combine unrelated issues under the same issue -- it makes it hard to read through the conversation and keep track of what is fixed. I'll be closing this issue, please reopen separate issues for things that are still important to you. |
Fedora 39 system, with 2 monitors attached.
I have several questions and still try to work out things.
Super
I see the same windows 2 times on both monitors. I expect to see the windows of each monitor only on each monitor ...I still have to figure out how to exactly reproduce this.
I turned off other extensions related to top bar or similar elements, just to debug this.
Thanks for any help, be patient with a newbie ... and thanks for PaperWM, works great on my laptops!
The text was updated successfully, but these errors were encountered: