Handler format overhaul, handler creation gui and game launch rework

[wunnr]

No description provided.

[davidawesome02-backup]

Hey, nice @wunnr!

Cool to see you merging this, I will start to work on some things I was going to port over to partydeck from my project, but didn't want to mess up your dev work on the new branch, so I hopefully can now :)

I got a few questions on this that I wasn't sure whether to post in a new ISSUE, or if you would prefer to stay uncluttered as it is related to this commit. I noticed you are now using "fuse-overlayfs" for the game binding... Is there a reason to use this over bwrap's existing --overlay-src and --overlay RWSRC WORKDIR DEST options? I just would imagine this would be more efficient for program requirements as bwrap calls the api directly (I belive) so we can avoid a fuse-overlayfs dep. Would you mind me changing this over to --overlay in a merge?

Would you mind a commit to remove some of the frankly unnecessary rust dependencies in this project currently. Namely:
fastrand - Used in 1 place to get a random number
rand - Used also to get 1 random number?
(Even if we absolutely require random, only one of these should be needed, and a simple LCG, could replace both dependencies against supply chain attacks that could randomly affect us)
rdf - Used to open 1 file picker, and could possibly be replaced by a feature in the dialog library that is also a dependancy
tar - I don't even see where this is used; It seams to be legacy and completely replaced by compress-tools
zip - This is only used once to extract zip files, because the only other use is still using a new zip process, removing at least the new command could reduce runtime dependencies, but compress-tools seams to support this as well, and is also seemingly unused in this project...
compress-tools - as stated above, it is not even used anymore, and thus can be removed, or be used to replace zip depending on your preference.
winit - Also seemingly completely unused anymore, seams we can just remove this one too.
Maybe:
semver- Could easily be replaced with a numeric release prefix, or just a not equals on the current name, as we are not expecting the latest release to be a backported change

Possible replacements for the dialogue boxes are not really required, but egui_dialogs exists, and may conform better with the current reliance on egui rather than using a completely different solution.

I am willing to make these changes if you are fine with them, or have any reason why not to...

Also, I have a few commits I will be attempting to make off of these I wanted to get comment on, I think will be better discussed on those commits when I get around to them, like
Implementing RIVERWM similar to my project's usage.
Implementing a new flag, or similar to allow for auto handler generation (something like partydeck -- %command% as a steam command to parse the required information.

If you have any comment on my changes over in gamescope, I am also hoping to get your input on that before I do anything that could mess up your project: ValveSoftware/gamescope#1897

Sorry for the annoyance @wunnr !

[wunnr]

Hey,

I agree that mounting the game dir using bwrap's overlay would be much easier and more performant as it uses the kernel's native overlayfs system rather than the userspace implementation provided by fuse-overlayfs. However, in testing I could not get bwrap overlays to work at all on SteamOS. I believe this is due to the Linux kernel's overlayfs not supporting case-insensitive filesystems until relatively recently, as looking through SteamOS' dmesg logs I got overlay: case-insensitive capable filesystem on [device] not supported after trying to run partydeck with bwrap overlays. If I was simply missing something or implementing something incorrectly, and you are able to get bwrap overlays to work on the latest SteamOS version, I would be happy to throw away the current fuse implementation; otherwise, maintaining Steam Deck compatibility is a huge part of my philosophy behind developing this, so fuse will have to do for now.

Regarding the dependency hell, yes, I would be eternally grateful to see the bloat reduced as much as possible. I have not been good about managing and optimizing dependencies so some project cleanup is definitely in order, whether that comes from me or someone brave enough to look at it.

Being able to do partydeck %command% for a steam game and have partydeck parse the entire steam launch command would definitely be a nice thing to have, but the current way handlers work might not be totally fit for that use case, so might require some rewriting, maybe a separate launch function? Hopefully the simplified handlers and Goldberg auto detection counts as a few steps towards making that happen.

Finally, regarding the gamescope fork, the original mouse/keyboard grabbing has proved super useful for partydeck, and I've just kept that original version of the fork for now, but I'll take a look at your updates and see if they would be useful to partydeck's goals. The auto-resizing option seems pretty useful, but I would need to make sure that on games that can't set their video mode dynamically (generally older games) that the feature doesn't produce unintended or weird behavior when the windows get resized.

[wunnr]

Also I don't believe we could completely get rid of rfd in favor of dialog::FileSelection because as far as I know the dialog crate doesn't have support for picking a folder instead of a file, which is used by dir_dialog() in util.rs when users need to locate their game's root path.

[davidawesome02-backup]

@wunnr

I agree that mounting the game dir using bwrap's overlay would be much easier and more performant as it uses the kernel's native overlayfs system rather than the userspace implementation provided by fuse-overlayfs. However, in testing I could not get bwrap overlays to work at all on SteamOS. I believe this is due to the Linux kernel's overlayfs not supporting case-insensitive filesystems until relatively recently, as looking through SteamOS' dmesg logs I got overlay: case-insensitive capable filesystem on [device] not supported after trying to run partydeck with bwrap overlays.

Good to hear the reasons for this selection, I will look into it; it might be possible to (while I would like to avoid it currently) ship our own "version" of bwrap as the overlayfs is the exact same as the overlayfs fuse is, just without the extra package. (also, while I DO NOT SUGGEST WE DO THIS CURRENTLY -- we can step away from bwrap to use our own kernel namespace calls eventually, just handling this our selves rather than calling to bwrap, and thus allowing for more features bwrap currently dose not fully support easily)

Also I don't believe we could completely get rid of rfd in favor of dialog::FileSelection because as far as I know the dialog crate doesn't have support for picking a folder instead of a file, which is used by dir_dialog() in util.rs when users need to locate their game's root path.
Regarding the dependency hell, yes, I would be eternally grateful to see the bloat reduced as much as possible. I have not been good about managing and optimizing dependencies so some project cleanup is definitely in order, whether that comes from me or someone brave enough to look at it.

If I have the time in the next few days, I will go through and remove some of the dependencies that are not required anymore, mostly those listed above, for now most likely I will keep random and rfd, unless I find that removing random entirely is just not required, as my friend advised for me not to rewrite a simple random instead of just using the crate.

Being able to do partydeck %command% for a steam game and have partydeck parse the entire steam launch command would definitely be a nice thing to have, but the current way handlers work might not be totally fit for that use case, so might require some rewriting, maybe a separate launch function? Hopefully the simplified handlers and Goldberg auto detection counts as a few steps towards making that happen.

I was thinking a new flag, to denote that all options after this flag, we could even just use the traditional -- are to be treated as a game launch, then we have two main options for how to launch, the easiest for maintainability, but harder to write, understand, and maybe add new features in would be to generate a simplistic handler just from the launch args.... we are already given the executable for proton, so we can just treat as a windows game, we just have to add overlayfs mounts, and not much else... This would also allow for exporting auto generated handlers. Our other option is just to make it launch with a new autolaunch.rs that would handle all this junk, maybe a full rewrite of launch code again into 2 generators of a common format that drive the launch.rs, but prob just generating the handler on launch would be best. I think that one could also allow us to write the handler data right beside the game, and scan that before we launch, allowing players to edit handlers for partydeck if they have issues with the auto generation, but just want to be able to click launch on steam.

Finally, regarding the gamescope fork, the original mouse/keyboard grabbing has proved super useful for partydeck, and I've just kept that original version of the fork for now, but I'll take a look at your updates and see if they would be useful to partydeck's goals. The auto-resizing option seems pretty useful, but I would need to make sure that on games that can't set their video mode dynamically (generally older games) that the feature doesn't produce unintended or weird behavior when the windows get resized.

I currently have only changed gamescope to allow the win+G grab / ungrab keybind, and was wondering how you belive this should be implemented should you wish to add this feature that is semi-implemented in gamescope already (SDL backend only, but wayland backend lies and says it works, but it legitimately only changes the title of the window to say Title (Grabbed). Also, currently separate, the gamescope nested resize (resize the game size when you resize the window, avoids the kwin breaking stuff if using a gamescope that supports it)