Add workspace name to separate applications in window switcher when using allWorkspaces=yes option about labwc

[droc12345]

.

[droc12345]

Had dropped old PR and put in a new one.
That's why I blanked out the previous comments as they had pointers to code that didn't exist anymore.

New code just got merged, has the ability to show workspace the window is on,
as well as state of window (min, max, full) and output name (if more than one output)

Consolatis is working on more enhancements to window switch OSD.

[droc12345]

You can try this patch, not exactly what you envision, but the same info in a different way and
it allows to set the workspace prefix (default Workspace) when using numbers instead of names.

https://github.com/droc12345/labwc/commit/46f153320ca5b9f40ba065f9b8a94a74cea8e9cf.patch

[johanmalm]

I think we're at a philosophical design-juncture here and I think the window-switcher is the first of its kind in labwc.

We ought decide early which route to take:

1. Keep adding configuration and theming options to render_osd()
2. Create multiple render_osd() implementations for 'pre-configured' window-switchers allowing much greater flexibility in approach.

I suspect (2) might be a good option here. Not that I want a cottage industry in making window-switchers, but it's probably a cleaner approach in support of making something more contemporary looking (like the one in mutter or similar). And given that there is no protocol for workspaces yet, and no way of communicating application thumbnails, I sort of feel that letting the compositor do some nice stuff here probably makes for better setups in where clients just can't do it.

Thoughts welcome.

[Consolatis]

Yes, thought about 2. as well for some time. Technically we could even go fancy and load other implementations dynamically from an external library path. Downside of that is that plugins (and thus labwc) will break on refactors if we don't define a API for them. And that in turn sounds like something I'd rather not spend time working on / maintaining at the current point.

In regards to the topic itself: we'd basically need to group the windows by workspaces before processing them, both in the osd and in desktop_cycle_view. Once that is done we can easily just check in the osd if the workspace of the current view to render differs from the last view rendered and then add a heading.

The implementation by @droc12345 can use the existing fields instead so its much easier to implement and users can configure it.

[johanmalm]

Technically we could even go fancy and load other implementations dynamically from an external library path. Downside of that is that plugins (and thus labwc) will break on refactors if we don't define a API for them. And that in turn sounds like something I'd rather not spend time working on / maintaining at the current point.

We think alike. In tree is better. And I reckon the only reason to ever go plugin with in-tree is if RAM becomes a problem. But for a few render_osd() implementations, I just can't see that being a factoring even worth considering.

[droc12345]

.

[droc12345]

I've though about this (OP), it would require rethinking how we do osd.
Right now, we get data, print a line, repeat (more or less).

To do this right with grouping/sorting, we would have to grab all the data, into something like an array of
structs, that would allow to sort on any element, ie, state, window type, output, workspace, etc.
And with an array of structs, we could put out part of the data, ie limit of # of lines
and then page/scroll for more data if needed.
Not particularly simple or easy, but I think this is the way to go to address the concerns from above.

[Consolatis]

We do already get the data as an array of structs, to be precise an wl_array() of struct view **.
Thus we technically could already sort and limit its size but the issue here is that the logic in desktop_cycle_view() uses the ordering in the server->views wl_list as well (it is also used as source of the wl_array() used in the OSD) so we actually select the next item shown in the OSD. When we end up modifying the order in the wl_array() used in osd.c we get out of sync and its basically random what application is selected on A-Tab.