New features discussion/requests #1

[wegel]

We'll centralize discussion on potential new features (or modifying existing ones) here.

[wilriker]

So one idea I have would be a quality of life improvement for me: the possibility to have an application appear on the workspace I was when I started that app.

I often get into the situation where I do something on e.g. workspace 2. Then I switch to let's say workspace 7 to fire up the app that I want to have there and move back to the previous workspace. If the app does not load quickly enough it will eventually appear on workspace 2 instead of 7. I know of the rules in config.h but I rather would prefer to not hard-code that decision to being able to start an application also on another workspace.

A possible solution might be one-time-rules.

Example usage: I have a script that I call with a keybinding that will walk a specific order of workspaces, load them on specific vouts, start a number of apps on each workspace and move on to the next (I use that to setup my working env after a restart of vwl). In order to have the apps actually appear on those workspaces I have to add sleep calls into the script. Otherwise nearly all apps land on the last loaded workspace.

[wegel]

The launch here, map later problem is a really hard one, across all window managers and X11/Wayland. I'll think about it.

[wegel]

See #21 .

[wilriker]

Going to test this in a bit! Thanks already!

[wilriker]

Request: would it be possible to include the cursor in sharing windows? It works for output sharing but sharing only a window will... yeah share only that window and of course visual effects that are produced by mouse interaction but the cursor itself is invisible.

[wegel]

My guess would be that we would need to disable hardware cursors; will investigate.

[wilriker]

AFAICT from wlroots source code they already handle cursor when sharing outputs (output.c). But they do not use that code when sharing toplevels.

[wilriker]

I am currently implementing this. I got it running locally in an MVP style. Will see where it gets from there.

[wilriker]

Request: I would love to see the Slack Huddle paint-on-screen feature working in vwl. It never worked for me in herbstluftwm and that feature is actually used quite a lot in the company I work for.

[wegel]

No idea what that entails; will investigate.

[wilriker]

What do you think about ext-workspaces-v1? I have a branch locally that has it implemented but I tend towards dropping it again as it turned out I only made minimal use of it at all.

[wegel]

I wouldn't be closed to it, especially if it lowered our core line count, BUT I'm wondering how good/badly it would integrate with the vout system; if we have to build a whole set of custom things on top of it to get them to work properly, I'd rather keep it out for now. But I could be convinced otherwise I guess if there was a really strong use case.

[wilriker]

So far it only adds lines of code since this is extra functionality. Right now all code related to using the vwlctl subscribe | jq ... method lives in ipc.c so even if we entirely replace it by ext-workspace-v1 it won't reduce LoC on vwl.c. Plus I think that the IPC status brings way more possiblity.

The only advantage would be an interactive widget in waybar since it is not easily possible to have use the current approach and make it clickable (since all ext/ modules in waybar only offer one single click-handler).

But so that you can have a look at what I did: #33.

[wilriker]

Another idea: having a separate border color for XWayland clients. I was using xwayland-satellite mainly to exactly know which clients use/need XWayland. Now I enabled XWayland in vwl and added a separate set of border colors for those. That is equally useful to me as explicitly using xwayland-satellite. Interested in a PR?

[wegel]

Yes, that's a good idea I would use it myself.

[wilriker]

There you go: #32

[wilriker]

It's cheating but: if you want to lower the LoC on vwl.c you could move debugstate to plumbing.c or even a debug.c (though the latter might come with even more overhead.

That would save around 100 LoC in vwl.c. ;-)