multiple monitors: strange behavior

[stefangweichinger]

Fedora 39 system, with 2 monitors attached.

I have several questions and still try to work out things.

• when I press Super I see the same windows 2 times on both monitors. I expect to see the windows of each monitor only on each monitor ...
• It seems I don't fully understand the "Scratch layer" (yes, I read the README): do windows get moved to the scratch layer as soon as I drag them by mouse?
• might be related to Scratch layer also: I see weird behavior with Chrome windows: for example I have browser windows on each monitor and if I move mouse from one monitor to the other, Chrome windows "hop behind" other windows. Very annoying if I have to cut and paste stuff from one browser window to another for example.

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!

[jtaala]

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):

https://github.com/paperwm/PaperWM/assets/30424662/910b77e3-c4b5-4412-8cb1-64dd44e3851f

However, if you drop NOT in a tiling boundary the window will be added to the Scratch layer:

https://github.com/paperwm/PaperWM/assets/30424662/74a2de57-2dcc-4036-963c-8d2f64360890

[stefangweichinger]

@jtaala thanks for the infos and the videos, understood. I will try to come up with a video asap.

[stefangweichinger]

@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.

[jtaala]

tiled windows and "scratch windows" somehow displayed differently?

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 are aren't used very much (I hardly used them at all - maybe when watching some video I might pop one out so its' above tiled windows)..

[stefangweichinger]

tiled windows and "scratch windows" somehow displayed differently?

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).

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 ;-)

Note: generally scratched windows are used very much (I hardly used them at all - maybe when watching some video I might pop one out so its' above tiled windows)..

"are used" or "aren't used very much" ? You write "hardly used at all" ... so I assume the second ...

[jtaala]

"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?

[jtaala]

Also note this from https://github.com/paperwm/PaperWM#scratch-layer (which sometimes confuses new players):

Opening a window when the scratch layer is active will make it float automatically.

Meaning if you have scratched window selected/active when you open another application - it will open also in the scratch layer.

[stefangweichinger]

Also note this from https://github.com/paperwm/PaperWM#scratch-layer (which sometimes confuses new players):

Opening a window when the scratch layer is active will make it float automatically.

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 ...

[stefangweichinger]

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.

[stefangweichinger]

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):

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.

[Lythenas]

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.

[jtaala]

I sometimes see no indicators, the dragged windows can't be dropped into "tiled position". thanks.

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: https://github.com/paperwm/PaperWM/issues/661#issuecomment-1789628782

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).

[jtaala]

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.

This is a good point - it might actually be handy / neat to have the indicators show up even for already scratched windows?

[Lythenas]

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.

[stefangweichinger]

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. On the laptop I don't have these issues: way more keyboard-based workflow, only one monitor -> easier.

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

[jtaala]

Can't tell exactly right now. And as far as I understand this is not intended behavior even with scratched windows displayed, right?

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.

[jtaala]

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

This already exists (see https://github.com/paperwm/PaperWM/issues/661#issuecomment-1789628782) - 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.

[jtaala]

My main issue as a new user might be, that on my desktop I seem to create scratched windows somehow without really noticing.

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:

Opening a window when the scratch layer is active will make it float automatically.

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).

[stefangweichinger]

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.

I will try to reproduce. Yesterday there were too many sensitive informations in all the windows, I couldn't share that as a video ;-)

[stefangweichinger]

My main issue as a new user might be, that on my desktop I seem to create scratched windows somehow without really noticing.

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:

Opening a window when the scratch layer is active will make it float automatically.

Yes, this might be my problem (of understanding): I will keep that in mind and see if it explains things better.

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).

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 ...

[Lythenas]

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?

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 Alt+Tab to focus the window works and then using the other shortcuts to move it to another monitor fixes the issue usually.

[stefangweichinger]

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.

[stefangweichinger]

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!

[stefangweichinger]

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.

[Lythenas]

@stefangweichinger this seems similar to the issue with wezterm #498

[stefangweichinger]

@stefangweichinger this seems similar to the issue with wezterm #498

Yes, thanks!

[stefangweichinger]

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

[stefangweichinger]

It's strange.

I have 2 monitors.

Having a window on the right monitor, right-click, then "move one workspace to the right" .. moves the window to the LEFT monitor.

In the Gnome settings the monitors are like this:

which is like their physical placement.

[jtaala]

This messes with my mental map of things: what is where right now?

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).

The overview often shows many empty workspaces and that also seems wrong.

This is from a gnome workspace paradigm clash (this one is much deeper) - see comment https://github.com/paperwm/PaperWM/issues/389#issuecomment-1911089672 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.

[jtaala]

Having a window on the right monitor, right-click, then "move one workspace to the right" .. moves the window to the LEFT monitor.

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.

[stefangweichinger]

@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.