[uberduper]

I'm probably not thinking about your use case the same way you are, but it seems like you could run a nested hyprland session in a 1920x1080 window and screenshare just the nested hyprland window. Run the apps you want to share inside that nested hyprland session.

I don't know of any reason that wouldn't work, but I haven't tried it so I'm not certain it would.

[nickjj]

I didn't even know that was possible but I think it would be the perfect solution, as long as it ran efficiently and managing the hotkeys between both sessions wasn't a problem. I wonder how that would work if you used the same configs.

If it were possible to pull off, that would be the perfect combo:

    - A dedicated 1920x1080 recording zone, using Hyrpland's config file to automatically resize and position this Hyprland session in whatever spot makes the most sense (top middle of a 4k monitor, etc.)
    - The nested session could use 1.5x or 2x scaling so fonts are larger on video[0]
    - There's no BS or manual steps because the nested session is a full fledged Hyprland set up, so tiling, floats, workspaces and app launching is fully working
    - Free to float whatever you want around the recording zone from the main Hyprland set up

[0]: On Windows with WSL 2 I work around this with a shell script I made to adjust my terminal's font size, etc.. I'd love to be able to drop that and have things be perfectly sized all the time when recording.

Edit:

The Hyprland docs mentions you should make a separate config and also avoid running any exec/exec-once commands. That could be a problem because I would want my wallpaper, mako, waybar and walker to come up in the videos which means running multiple copies of these.

Maybe it could work tho in the end. I will play with it and see how it goes. Thank you for introducing me to the idea, even if it doesn't work, it's an interesting concept.

[uberduper]

I've only used it for testing/debugging so I didn't need any of that capability. I'm not sure why they recommend avoiding exec in the config. Since it would still be under the same user session, dbus things could get wonky. Nested hyprland will automatically create/use ~/.config/hypr/hyprlandd.conf and you'll def want to have unique keybinds. If you haven't gone too crazy with keybinds, just changing the main mod key (I used capslock) in the nested config should take care of most things.

[nickjj]

Thanks yeah, I didn't go too crazy with binds yet. Maybe ALT + TAB is the only thing that's not using the main mod key.

It's probably going to get complicated though due to wanting to run waybar, walker, wallpaper, etc. in the nested session but if you do anything that's going to modify its state in that session is also going to affect the outer one since only 1 process runs for those tools.

It's almost like you need a separate copy for everything that runs in exec but with a different process name too.

[christophilus]

Yep. I’ve done this with Niri, too. It’s a really nice capability.

[nickjj]

How did you end up managing things like waybar?

You'd end up with 2 copies of it running and you typically killall/pkill to reload it because it's expected you'd only run 1 copy but now with this nested solution there's 2 copies running.

The only thing really stopping me from Niri is it doesn't seem to have dynamic configs to let you have 1 main config and then source in a smaller 2nd config to overwrite settings in the main config.

That's really useful for having personalized changes per device or overwriting specific colors to change themes.

Hyprland has a `source` feature for this.