firefox's picture in picture mode does not show when firefox window isn't focused

[phillbush]

Hi,
I did not thought about Firefox's picture-in-picture mode when I implemented sub-window grouping in shod.

This occurs because some applications spawns lots of sub-windows (mostly palettes and menus) that are used to control a main window. The most obvious example is Gimp: in its multi-windows mode, the tools palette and the brushes palette (and others, depending on the configuration) are configured as sub-windows, as you can see in the screenshot below. You can even spawn menus as sub-windows:

In order to unclutter the window list (in a taskbar, for example) shod groups sub-windows along with their main window. And in order to unclutter the windows themselves on the screen, shod hides the sub-windows when their main window loses focus. As you can see in the screenshot below (the palette windows are still there, but they are not visible until Gimp be focused again):

However, there can be situations where the main purpose of a sub-window is to be visible when its main-window is not, which is the case for Firefox's picture-in-picture mode. I did not thought on those situations when I implemented such feature in shod.

First, I'll hardcode picture-in-picture windows to not be interpreted as a sub-window (for Firefox to just work by default). Then I'll change shod's rules system so the user can manually configure exceptions to the sub-window grouping behavior (for any other similar case).

[aspizu]

thank you for this project ( and all of your other projects).

[phillbush]

Done.

I added a .rules field in config.h for hardcoded rules (Picture-in-Picture is the only hardcoded rule for now). The user still can set up rules in ~/.Xresources (or ~/.Xdefults, etc).

However, I changed drastically the path to the resources. Previously, a rule resource was required to match a window class (shod.class.XTerm.type) or a window name/instance (shod.name.myterm.type), but you could not specify a rule for a window matching both properties. There was also not possible to match a window by its role.

Now you can match a window by its class and/or name and/or role, using a resource like shod.CLASS.NAME.ROLE.type. For example, to set the type of a window whose class is XTerm, name is myterm, and unknown role, you must now use the resource shod.XTerm.myterm.?.type. To set the type of a window of role picture-in-picture, you must use the resource shod.?.?.Picture-in-Picture.type (or shod*Picture-in-Picture.type). More info on the manual.

I also pushed some local changes I have been experimenting locally on my computer:

• Pass shod(1) some sh(1) commands to be run after shod has initialized its properties.
• Use BSD's sys/queue.h rather than implementing queues myself (this may be included Linux, idk).
• Several bugfixes, mainly on autoresizing of menus and dialogs.

All in all, firefox picture-in-picture now works out of the box.

[aspizu]

Thank you, this fixes the issue of the PIP window not appearing but now introduced another issue where it does not stay on top of all windows.

[phillbush]

Thank you, this fixes the issue of the PIP window not appearing but now introduced another issue where it does not stay on top of all windows.

That's because shod does not honor the window state requested by the application at creation time. For example, if Firefox creates a window (such as PiP) requesting it to be above all others, shod will not honor it. Shod only honors manual requests from the user (with shodc state -a).

But this behavior is easy to change. I will implement the feature to honor application requests at window creation time.

[aspizu]

Thank you

[phillbush]

Done.
Now Picture-in-Picture windows are both visible and stay above other windows by default.