I really wish the full potential of compositing window managers could have been fulfilled, instead of the tech behind them being used for mostly eye candy.
Here are two items that should be doable with compositing. First, when giving a presentation with an external monitor, I'd like to tag specific windows to be mirrored (and scaled, if appropriate) on the secondary monitor. That way I can still be messing with my instant messages or email in private (which you can't do if you are mirroring your whole screen), yet be able to easily work with content that the audience is also viewing (by no having to shift my head from my laptop screen up to the projector all the time). This would be similar to using online meeting software where you share specific windows.
The second item, that you can sort of do now but not cleanly, is have multiple mice and keyboards, so that a mouse that selects a given window gives its associated keyboard input focus to that window. While the other mouse/keyboard combo is working with a different window. This would be great for pair programming, especially with a multi-windowed shared buffer editor (like what Emacs can do).
You can do this now, with some editing in the X config file, but there is no indication on the screen which window currently is focused to which keyboard -- this can be accomplished with the WM changing the window border or title bar color as appropriate.
This sort of thing is extremely difficult on X, but very doable on Wayland. I've been thinking about putting broadcast/streaming functionality directly into a compositor, so that your presentations/scenes could be composited separately from your actual windows. Think OBS, but the components/layers of the presentation are Wayland surfaces, and vice-versa, the windows are layers of the presentation. In this sort of system, the compositing can easily happen on the GPU, and can be accelerated like any desktop compositing.
This sort of thing is extremely difficult on X, but very doable on Wayland.
I'd say it is the other way around. With Wayland you'd need buy-in from the entire stack since in Wayland everything needs to be implemented in the compositor. With X all you need is a compositor (not necessary even your window manager, it can be a separate compositor) that ignores the area of one monitor when compositing and instead renders duplicates of the tagged windows there. You can keep using everything else you were already using.
I'm not clear on how this would happen on wayland as I haven't done any development on it yet, but with X it would be tricky since the server still has the window hierarchy state for event routing etc.
If you simply mirrored redirected windows in triplicate all over the place in the compositor, it wouldn't magically make the window manager and X server aware of all those areas as being windows to manage and route events at. You'd just have these ghost windows that can't be directly interacted with as first-class windows.
You'd just have these ghost windows that can't be directly interacted with as first-class windows.
But that is what the GP asked for, not full duplication.
Though if you want duplication it might be possible by creating a window over the duplicated area that the compositor does not render but still grabs all input events that are then forwarded to the original windows via XSendEvent.
I myself have been wondering why no one has made something like a complete software A/V router for this. Plug the output of any application through filters, splitters, muxers, duplicators, whatever, and ultimately out via your chosen sinks. Represent the whole thing in a 2d flowchart like QjackCtl or something.
This is sort of what PipeWire is for, as far as I'm aware. The one advantage of a more monolithic approach (where most of the AV handling is done in the same way as ordinary desktop compositing) is that buffers that originated on the GPU don't need to leave it until very late in the process. If you're really careful, no buffers leave your GPU except encoded complete compositions.
First, when giving a presentation with an external monitor, I'd like to tag specific windows to be mirrored (and scaled, if appropriate) on the secondary monitor. That way I can still be messing with my instant messages or email in private (which you can't do if you are mirroring your whole screen)
You could start another X server for the secondary display and drive it via vnc or something like that. It's a different approach, but checks most (all?) Of the boxes.
Malleability of certain display characteristics is an important feature (largely for accessibility reasons), eye-candy is just marketing and signaling.
While I understand not wanting any useless eye-candy for functional purposes, I think there is also pleasure derived by simply "looking at pretty things".
It does not need to involve any external motivations.
"Eye-candy" can be supportive of said malleability.
Inferring form what you wrote, I think your working definition of marketing is wrong. Maybe you can clarify what you mean by "marketing"?
I am also unsure what you mean with "signaling". If you mean communication with the user via visual cues, than I would say signaling is an important feature.
Eye-candy is important with many things made for humans, not just computer displays.
By "marketing" and "signaling", I mean ricing. People want their GUIs to look pretty mostly as a way to either sell them or express their fashion sense to others.
I feel like the sweet spot for malleability was Win95-era theming. You could adjust the color of everything, and the typeface of everything, and that was it.
What's up with this glorification of Win95 style UI?
It's objectively ugly. Everyone I know or have known, in my entire life, without question, thought so back then, and does so now.
I am just so, so puzzled by this I had to type out this comment. Ignoring functionality, accessibility and all that, does anyone actually think it looked aesthetically pleasing, and I don't mean that in a 20-years-after nostalgic vaporwave way? Why is there a sudden wave against things being allowed to look nice and pleasing to the eye?
I liked it, for one. Especially after win3.1 The 3D buttons were much better than the flat rectangles in vogue today.
The UI might not have been perfect, but they gave an interface that provided a decent feedback while getting out of the way if you wanted to get work done.
Now if this is against being allowed to look pleasing? That depends on what you are comparing against, of course. Next and osx i could live with equally well, i guess. Modern win10, otoh, should be shot.
But thats my opinion. Do on your PC whatever you want.
"Instead" refers to the exclusivity of eye candy. So I'd rather see additional features enabled instead of an exclusive focus on flaming or squigly windows. Both would be fine, but if I had to choose...
Ok, understood. There is a diminishing return with every additional feature. I have to have a use case for every feature, otherwise it is useless and only takes up resources. My maximum number of use cases is finite.
Comments
I really wish the full potential of compositing window managers could have been fulfilled, instead of the tech behind them being used for mostly eye candy.
Here are two items that should be doable with compositing. First, when giving a presentation with an external monitor, I'd like to tag specific windows to be mirrored (and scaled, if appropriate) on the secondary monitor. That way I can still be messing with my instant messages or email in private (which you can't do if you are mirroring your whole screen), yet be able to easily work with content that the audience is also viewing (by no having to shift my head from my laptop screen up to the projector all the time). This would be similar to using online meeting software where you share specific windows.
The second item, that you can sort of do now but not cleanly, is have multiple mice and keyboards, so that a mouse that selects a given window gives its associated keyboard input focus to that window. While the other mouse/keyboard combo is working with a different window. This would be great for pair programming, especially with a multi-windowed shared buffer editor (like what Emacs can do).
You can do this now, with some editing in the X config file, but there is no indication on the screen which window currently is focused to which keyboard -- this can be accomplished with the WM changing the window border or title bar color as appropriate.
This sort of thing is extremely difficult on X, but very doable on Wayland. I've been thinking about putting broadcast/streaming functionality directly into a compositor, so that your presentations/scenes could be composited separately from your actual windows. Think OBS, but the components/layers of the presentation are Wayland surfaces, and vice-versa, the windows are layers of the presentation. In this sort of system, the compositing can easily happen on the GPU, and can be accelerated like any desktop compositing.
I'd say it is the other way around. With Wayland you'd need buy-in from the entire stack since in Wayland everything needs to be implemented in the compositor. With X all you need is a compositor (not necessary even your window manager, it can be a separate compositor) that ignores the area of one monitor when compositing and instead renders duplicates of the tagged windows there. You can keep using everything else you were already using.
I'm not clear on how this would happen on wayland as I haven't done any development on it yet, but with X it would be tricky since the server still has the window hierarchy state for event routing etc.
If you simply mirrored redirected windows in triplicate all over the place in the compositor, it wouldn't magically make the window manager and X server aware of all those areas as being windows to manage and route events at. You'd just have these ghost windows that can't be directly interacted with as first-class windows.
But that is what the GP asked for, not full duplication.
Though if you want duplication it might be possible by creating a window over the duplicated area that the compositor does not render but still grabs all input events that are then forwarded to the original windows via XSendEvent.
For a presentation, the non-interactivity might even be more of a feature than a bug.
I myself have been wondering why no one has made something like a complete software A/V router for this. Plug the output of any application through filters, splitters, muxers, duplicators, whatever, and ultimately out via your chosen sinks. Represent the whole thing in a 2d flowchart like QjackCtl or something.
This is sort of what PipeWire is for, as far as I'm aware. The one advantage of a more monolithic approach (where most of the AV handling is done in the same way as ordinary desktop compositing) is that buffers that originated on the GPU don't need to leave it until very late in the process. If you're really careful, no buffers leave your GPU except encoded complete compositions.
https://pipewire.org/
You could start another X server for the secondary display and drive it via vnc or something like that. It's a different approach, but checks most (all?) Of the boxes.
Why "instead"? Best would be to have both. Eye candy is an important feature. No need to sacrifice one to get the other.
Malleability of certain display characteristics is an important feature (largely for accessibility reasons), eye-candy is just marketing and signaling.
While I understand not wanting any useless eye-candy for functional purposes, I think there is also pleasure derived by simply "looking at pretty things".
It does not need to involve any external motivations.
"Eye-candy" can be supportive of said malleability.
Inferring form what you wrote, I think your working definition of marketing is wrong. Maybe you can clarify what you mean by "marketing"?
I am also unsure what you mean with "signaling". If you mean communication with the user via visual cues, than I would say signaling is an important feature.
Eye-candy is important with many things made for humans, not just computer displays.
By "marketing" and "signaling", I mean ricing. People want their GUIs to look pretty mostly as a way to either sell them or express their fashion sense to others.
I feel like the sweet spot for malleability was Win95-era theming. You could adjust the color of everything, and the typeface of everything, and that was it.
What's up with this glorification of Win95 style UI? It's objectively ugly. Everyone I know or have known, in my entire life, without question, thought so back then, and does so now.
I am just so, so puzzled by this I had to type out this comment. Ignoring functionality, accessibility and all that, does anyone actually think it looked aesthetically pleasing, and I don't mean that in a 20-years-after nostalgic vaporwave way? Why is there a sudden wave against things being allowed to look nice and pleasing to the eye?
I liked it, for one. Especially after win3.1 The 3D buttons were much better than the flat rectangles in vogue today.
The UI might not have been perfect, but they gave an interface that provided a decent feedback while getting out of the way if you wanted to get work done.
Now if this is against being allowed to look pleasing? That depends on what you are comparing against, of course. Next and osx i could live with equally well, i guess. Modern win10, otoh, should be shot.
But thats my opinion. Do on your PC whatever you want.
"Instead" refers to the exclusivity of eye candy. So I'd rather see additional features enabled instead of an exclusive focus on flaming or squigly windows. Both would be fine, but if I had to choose...
Ok, understood. There is a diminishing return with every additional feature. I have to have a use case for every feature, otherwise it is useless and only takes up resources. My maximum number of use cases is finite.