foreign-toplevel-management: Report the surface's parent #52
Conversation
|
Note that this will only work if the client has bound an object to the parent toplevel. |
Since toplevels are not globals, but are server-created objects via the However the docs should specify what happens if the client has destroyed the toplevel that is the parent. No event? Event with null? I'd also like to see a working implementation, just to make sure there are no issues we missed. |
|
Ping? This would be really great to have in the proto |
|
Send patch? |
|
Hi, I'm interested in having this functionality and started working on an implementation. So far, what I've tested is the simple rule that child views should not be displayed in the taskbar as separate icons. I have not tested more complicated functionality (grouping / mapping views together). I'm happy to create other examples beside cairo-dock which is a complex case, if needed. Should I create separate PRs for wlroots and wayfire? Thanks! |
Yes, the protocol is waiting for implementation :) |
IMO no event makes more sense than event with null. After all, null events means no parent. Otherwise LGTM. |
|
OK, no event makes sense to me. After all, if the client has destroyed the toplevel, it's on them. Can you add it to the protocol description? |
Some window switchers, like mobile ones, may want to skip or group dialogs and other child windows on their window lists. Right now the only way to group toplevels is to use app_id, which will end up grouping too much in case of multiple toplevels with separate documents. Reporting on the toplevel's parent makes it easy to distinguish separate window stacks and act accordingly.
|
Is this wording okay? |
based on the proposed PR: swaywm/wlr-protocols#52
|
Thanks! |
Based on the wlr-protocols PR: swaywm/wlr-protocols#52
see swaywm/wlr-protocols#52 Windows that have a parent are ignored (not shown in the taskbar, since these are usually dialogs). Also re-wrote the logic for identifying and deciding when an icon should be shown for a foreign-toplevel. Signals are now always emitted by the done event handler. Additionally, improvements to parse app ID under Wayland as well Moved the functionality for this from cairo-dock-X-utilities.c to cairo-dock-windows-manager.c (as a new function: gldi_window_parse_class()), this is now used by both the X and Wayland backends. This fixes issues by not recognizing some apps (e.g. Firefox and gnome-terminal if using XWayland) due to the app ID not matching the expected case.
see swaywm/wlr-protocols#52 Windows that have a parent are ignored (not shown in the taskbar, since these are usually dialogs). Also re-wrote the logic for identifying and deciding when an icon should be shown for a foreign-toplevel. Signals are now always emitted by the done event handler. Additionally, improvements to parse app ID under Wayland as well Moved the functionality for this from cairo-dock-X-utilities.c to cairo-dock-windows-manager.c (as a new function: gldi_window_parse_class()), this is now used by both the X and Wayland backends. This fixes issues by not recognizing some apps (e.g. Firefox and gnome-terminal if using XWayland) due to the app ID not matching the expected case.
see swaywm/wlr-protocols#52 Windows that have a parent are ignored (not shown in the taskbar, since these are usually dialogs). Also re-wrote the logic for identifying and deciding when an icon should be shown for a foreign-toplevel. Signals are now always emitted by the done event handler. Additionally, improvements to parse app ID under Wayland as well Moved the functionality for this from cairo-dock-X-utilities.c to cairo-dock-windows-manager.c (as a new function: gldi_window_parse_class()), this is now used by both the X and Wayland backends. This fixes issues by not recognizing some apps (e.g. Firefox and gnome-terminal if using XWayland) due to the app ID not matching the expected case.
Some window switchers, like mobile ones, may want to skip or group dialogs and other child windows on their window lists. Right now the only way to group toplevels is to use app_id, which will end up grouping too much in case of multiple toplevels with separate documents. Reporting on the toplevel's parent makes it easy to distinguish separate window stacks and act accordingly.