ewmh patch installed, but polybar xworkspace module doesn't work correctly

[UltLight]

as the title says, the xworkspace module has the pin-workspaces = true and xprop -root _NET_DESKTOP_VIEWPORT returns _NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0. is this a problem with the ewmh patch or polybar?

[bakkeby]

Yes I would not expect this to work at all as the feature is intended for classical desktop environments.

Let's say that you are using gnome or KDE with four desktops (we can refer to these as workspaces) and that your old CRT has a whopping resolution of 1600 × 1200.

The X displayable area is 10000x10000 pixels. Traditional desktop environments as intended have a different viewport for each desktop, so they may be lined out in a row like:

• desktop 1 at y 0 x 0
• desktop 2 at y 0 x 1600
• desktop 3 at y 0 x 3200
• desktop 4 at y 0 x 4800

or in a grid like:

• desktop 1 at y 0 x 0
• desktop 2 at y 0 x 1600
• desktop 3 at y 1200 x 0
• desktop 4 at y 1200 x 1600

So when you move to different workspaces / desktops the viewport (referring to the section of the X displayable area that the monitor is showing) changes and the _NET_DESKTOP_VIEWPORT hint is updated and programs that are avid fans of such information (like polybar) can react to this. Some bars may show a small screenshot of each desktop / workspace / viewport for example.

This change of viewport is also why you may find animation like in gnome where the windows go from left to right and vice versa when changing desktops, or that famous 3D qube effect from KDE. You may also note that in this scenario you can not have different desktops per monitor - all monitors combine into one view and one desktop.

If you have three monitors or one very large screen then there is a limit on the number of desktops you can have adjacent to one another without overlapping - hence you are typically restricted on the number of desktops you can have in a desktop environment.

In general you may find that X (and Wayland for that matter) as well as all the extended window manager hints are designed around desktop environments and stacking / floating window managers.

When it comes to most tiling window managers you will find that they work differently with respect to workspaces and that they typically have a static viewport. In dwm when changing tags the client windows that are not visible are simply moved out of the way to a negative x position, and they are moved back into view when shown. Most other window managers take advantage of the the iconic window state (which basically just means minimized) and they map and unmap windows as they go into and out of view.

The ewmhtags patch for dwm merely sets the a handful of properties:

• _NET_NUMBER_OF_DESKTOPS e.g. 9 (number of tags)
• _NET_CURRENT_DESKTOP e.g. 8 (the last selected tag on the current monitor)
• _NET_DESKTOP_NAMES e.g. "1", "2", "3", ..., etc.
• _NET_DESKTOP_VIEWPORT set to 0, 0 (as that is the static viewport of dwm)

If you feel compelled to use polybar with dwm then you may want to consider using the polybar-dwm-module by the same guy who made the IPC patch (which would also be a dependency). It allows for a more tight integration between tags in dwm and what polybar shows in terms of workspaces. I have never tried this myself so I can't comment on how well it works or how easy it is to patch when it comes to upstream changes for polybar.

[UltLight]

I see, thank you for the insight. I've been reluctant on using the polybar-dwm-module for of polybar because it hasn't had a new commit in around 9 months, but I'll try it out.