Multiple windows/outputs for wayland backend? Ideas to use wlroots/wayfire as a GUI framework to glue apps together

[digitalsignalperson]

I'm not sure if wayfire/wlroots is built for this, but it would be cool to build applications which are nested compositors where the widgets/windows of this application are composed of wayland clients managed by the app. Ideas:

• rootless passthrough mode with wayland backend: from the outside it doesn't look like you are using a nested compositor
  • variation on this: apply custom shaders to different applications, or do anything acting as a wayland proxy between the desktop compositor and the clients
• glue applications together in different ways:
  • wayfire/wlroots is like your gui framework. you launch different clients which are treated like widgets that you can put in different windows and containers, or per wayfire style put them in 3d scenes
    • Note: if wlroots can only provide a single output for the wayland backend, we are limited to creating applications with one window only. I have a feeling this is currently the case, but I'm not 100% sure.
  • E.g. making a file manager or a text editor application and "embed" applications like pdf viewer, video player, as thumbnails, which you can click to zoom in, and maybe click a button to pop them out into their own window
  • E.g. customizing a web browser: Say your "app" embeds firefox, but you code it to chop off the top tab bar and behind the scenes use mouse/keyboard macros to interact with tabs. And maybe you bolt on your own widgets to take notes and screenshots. And the multiple windows/outputs which allow new top level windows from the web browser to be rootless from the outside perspective

I recently found this Wakefield compositor that is a POC for some of this. It's a compositor that is GTK class/container, and clients can be placed in a gtk window just like other widgets and arranged in containers like vbox, hbox, etc.

• https://github.com/magcius/wakefield is the original repo
• https://github.com/alexlarsson/wakefield is a fork with further development including xdg-shell, but I couldn't get it to work (gtk3 using different xdg-shell protocol I think)

Also this idea has some similarities to a wayland proxy, which there are some interesting ones around:

• https://github.com/wayland-transpositor/wprs
• https://gitlab.freedesktop.org/mstoeckl/waypipe
• https://github.com/talex5/wayland-proxy-virtwl
• https://gitlab.freedesktop.org/jonleivent/waydapt

A wayfire/wlroots rootless-passthrough-like wayland backend would essentially be a fancy proxy too.

[soreau]

I've actually considered a plugin that does this, though there are many corner cases to consider. You could make it such that you can mod+drag to select a portion of a window, after which the rest of the window would become transparent (and click-through). Then do this to other windows and finally snap them together with a special move-drag binding provided by the plugin.

However, one of the problems is that you would have to repeat these steps when restarting 'the window'. Another problem is that if the app changes the location of the selected area within the main app, you would also have to redo the selection and snapping, or otherwise prevent the client from changing the target area geometry.

You can however dynamically create and destroy wayland backend outputs in wayfire, using stipc and ipc plugins, and script it to make each application start in its own output.

[digitalsignalperson]

You can however dynamically create and destroy wayland backend outputs in wayfire, using stipc and ipc plugins, and script it to make each application start in its own output.

Nice, if that already works with the nested Wayland backend to be able to open more windows, then implementing this idea could work. Like you say scripting apps to start in their own output, and whenever they open new windows instantly moving them to new outputs and forcing them to stay maximized/locked to that output.

However, one of the problems is that you would have to repeat these steps when restarting 'the window'. Another problem is that if the app changes the location of the selected area within the main app, you would also have to redo the selection and snapping, or otherwise prevent the client from changing the target area geometry.

It sounds like the plugin you are describing is around gluing things together dynamically, vs my idea is that you create a stand-alone program or script that runs its own compositor. So you avoid repeat steps because it's hard coded how the clients your program will behave.

More elaboration:

• Base desktop compositor: could be wayfire, KDE, or otherwise
• Custom application
  • is a client of the base desktop compositor
  • spawns its own nested wayfire compositor (or plain wlroots or otherwise)
  • spawns a bunch of clients it will glue together
  • is coded to render the surfaces of the client applications in any way desired through layouts in one window or multiple windows
  • has rules for what happens when a client creates a new window, which could be tiling within one output (a window on the base desktop compositor), or could involve opening more windows in the base desktop compositor and applying window rules to lock it to that output