gtk3 dialogs dont get associated with parents right

[nagisa]

• Sway Version: 1.5.1

• Debug Log:

sway.log

• Configuration File:

/dev/null (the defaults)

• Description:

I'm finding that dialogs created by gtk3 apps don't really stick on the same workspace as the parent of the dialog. For instance the file-roller's completion notification will show up on whatever workspace is focused at the time dialog is created rather than the workspace where the parent window is.

This can be reproduced with gtk3-demo dialog example as well:

1. Start gtk3-demo;
2. Choose "Dialogs and message boxes";
3. Click "Run";
4. Click (but don't release) the "Message dialog" button;
5. While holding the mouse button, switch to a different workspace;
6. Release the mouse button;
7. Observe the dialog being created in the currently focused workspace.

This is somewhat annoying, because e.g. if dialog is something that shows up as a result of some long-running task, one may have started procrastinating, while the task is ongoing. In my case procrastination typically involves looking at a fullscreened mpv. The completion dialogs will then generally appear under this window. These dialogs also disable interaction with the parent window. So this behaviour be confusing when users end up with "stuck" windows with no clear way of proceeding.

[Xyene]

I'm finding that dialogs created by gtk3 apps don't really stick on the same workspace as the parent of the dialog.

The behavior Sway implements here is the same as i3's. See https://github.com/i3/i3/issues/4242; this may change in the future, but is not a bug. Nonetheless,

In my case procrastination typically involves looking at a fullscreened mpv. The completion dialogs will then generally appear under this window.

wouldn't be helped by this change. Popup windows from an app that isn't fullscreen won't be displayed over one that is. popup_during_fullscreen allows you to control this behavior somewhat; perhaps popup_during_fullscreen leave is closest to what you want.

[nagisa]

wouldn't be helped by this change.

Well, it would help in a sense that the window wouldn't get as lost as it does right now. I almost never un-fullscreen mpv myself, so there's rarely an opportunity to see what's under it. And I don't really have a way to tell sway to avoid the workspace where mpv generally lives AFAICT.

perhaps popup_during_fullscreen leave is closest to what you want.

Huh, the documentation suggests that this only affects fullscreen windows that are creating the dialogs, and not currently focused fullscreen windows when any other application is creating dialogs. I'll play with it.

[crafter999]

It's something like a bug and somewhat annoying. I managed to overcome this by opening the application inside the same workspace. For example if I run Firefox from workspace 1 and assign it to workspace 2, popup with show up at workspace 1 BUT if I run (from workspace 1) sway workspace 2; sway exec firefox, everything's good as expected, popup at workspace 2. There should be mentioned somewhere in the docs though.

[Vladimir-csp]

In order to not loose such dialog if behavior is changed, it can be marked urgent. Due to this bug it is impossible for example to do something else while audacity imports multiple audio files, because it spawns an import progress dialog for every file. Sway puts them on active workspace and gives focus, despite parent window is not on screen.