add support for workspace 10

[hboetes]

I really need workspace 10 to make mangowc work for me.

[hboetes]

Now you may or may not agree with the necessity of the additional workspaces, but the not using hardcoded values in src/fetch/monitor.h is certainly an improvement.

[Yappaholic]

It's not about agreeing on the necessity, it's about complying with DWL IPC since it requires having 9 tags only and changing it will break both IPC and apps that depend on it

Also you changed formatting, which is no good

[gplusplus314]

The whitespace formatting can certainly be fixed, no big deal. But let's talk about DWL IPC.

While it may be true that it might break DWL IPC for some specific apps, that's actually an improvement. If some downstream code is relying on Mango to replace any workspace greater than 9 with 9, then it's coded against a bug and should break. If something breaks due to this change, then it's worth breaking.

Consider the fact that Mango is not DWL, it's just based on DWL. DWL is actually unmaintained at the moment; MangoWC is further ahead of DWL by quite a bit. In fact, DWL doesn't actually have IPC; there's a well known patch that adds IPC, but in its purest form, DWL does not have IPC.

Now, looking at Mango's IPC, which admittedly is identical in function to the well known DWL IPC patch, every single representation of a tag or tag mask is a uint32_t, just like the rest of Mango's internals, so there is no reason to limit it to 9 tags when the primitive already supports 32 tags. Both sides of the IPC already see tags as a uint32_t; the IPC itself is unaffected.

Keep in mind that DWM is the inspiration behind DWL, and DWM definitely supports more than 9 tags. Here's a direct quote from dwm.c:273 proving this:

/* compile-time check if all tags fit into an unsigned int bit array. */
struct NumTags { char limitexceeded[LENGTH(tags) > 31 ? -1 : 1]; };

Obviously the whitespace formatting needs to be fixed, but that's not a big deal. Aside from that, this change looks valid to me. This isn't my project, though; I'm just a former DWM user who is switching to Wayland and doesn't want to start from DWL.

From a UX perspective, there are 10 digits on a number pad/row. I think this makes sense. This PR is a net improvement, IMO.

[hboetes]

What I forgot to mention: initially I added bind=SUPER,0,view,10,0 to my config, and when I pressed SUPER+0, I got to see workspace 2 and 4 at the same time. I bet you can reproduce that.
This is because it triggers parts of the overview mode because of the inner working of mangowc, multiple bits are set and voila, you see multiple workspaces.

[Yappaholic]

Hmm, if this will not break DWL IPC and other apps, then why only go for 10? Some compositors like river support up to 32 tags, so tag length should be 9 by default and should be able to be set in the config

[DreamMaoMao]

To be honest, since we now support ext-workspace, it has no restrictions at all. I originally intended to completely abandon dwl ipc and then use an independent ipc socket. This way, many functional requests can also be resolved, such as obtaining all client states through external tool requests, etc

For a specific workspace 10, I tend to implement a named workspace that is not limited by quantity

[zenoli]

+1 for named workspaces.
#274

[hboetes]

I fixed the whitespace discrepancy.

[gplusplus314]

Hey @DreamMaoMao , I took a look into the Mango code a bit more and I don't think the ext-workspaces-v1 implementation is "unrestricted", as you've stated. It seems the Workspaces are directly mapped to tags. So the limitations of tags are imposed on the Workspaces, and thus, the main branch only supports 1+9 Workspaces: a special overview Workspace, then the 9 tags.

This PR actually demonstrates the issue. Notice how static const char *tags[] and static const char *names[] need to be updated in parallel. One solid example of the two needing to be logically identical can be seen in mango.c:3080 (in void createmon):

	for (i = 1; i <= LENGTH(tags); i++) {
		add_workspace_by_tag(i, m);
	}

To truly generalize Mango's implementation of the ext-worspaces-v1 protocol, the tags and Workspaces need to be two different structures, with the Workspaces being dynamically allocated. You'd also need a different IPC mechanism to allow the other window/client operations ("Move to Workspace N", etc) that isn't covered by the ext-workspaces-v1 protocol. This would be a much larger change with a pretty good chance of breaking something.

For an immediate improvement, would you consider this PR, or even this PR expanded to 32 tags? This is fully compatible with existing IPC and the existing Workspaces implementation (direct map to tags). There is a non-zero amount of people who would benefit from this, plus it's a very small, low-risk change that doesn't even introduce any new code paths.

[gplusplus314]

I've drafted an alternative implementation in #739 that makes the number of tags configurable, clamped to [1, 32] to stick with the same bitwise representation of tags. I think this would satisfy the needs of both @hboetes and @Yappaholic and still preserves existing functionality. Feedback and testing is appreciated. 🙂

[hboetes]

I'm all in favour of #739. It's a clean, well-thought-out PR, which fixes the multiple issues, and doesn't conflict with further improvements. Job well done, @gplusplus314

[gplusplus314]

Much appreciated, @hboetes . If you have time, let's try to test edge cases in #739 . Thanks!