moonlight-qt

moonlight-qt copied to clipboard

This commit addresses Issue #448 by adding a command line option that allows the listing of all the Apps reported by the remote host as a CSV.

I wasn't sure what the best output format would be and what information to include. So for the first iteration I went will all available information about an App and the path to the cached box art as CSV. Since it is a simple printf that could be easily adapted if desired.

I gave this a shot and there are some problems (not really the fault of your change, just how Moonlight currently works) that prevent it from being a good user experience right now IMHO.

1. It doesn't work at all on Windows. We are a Win32 subsystem app which means we don't have a console to write to unless we AttachConsole(). I'll need to look into that.
2. Even on platforms where it does work, like macOS and Linux, the output is full of log spam from polling PCs, initializing FFmpeg, etc. I'll need to add some way to maybe increase the minimum log level when running a command like list where terminal output is expected.
3. Because a Moonlight window appears when the list command is running, this pretty much precludes any background usage by launchers like Playnite. It's also just generally intrusive for human use too. I'm running moonlight list from the terminal to write output to that same terminal. Having windows flying around in the process of printing the console is really dumb (again, not your fault, just not something we've plumbed yet).

I'm going to skip this for v3.1.0 due to those issues, but I would like to get these addressed for the following release.

I currently don't have a Windows system for testing to my disposal (nor have I done a lot Win32 programming in the past, tbh), so I cannot say much regarding that point. Regarding the second point, I only had this issues with a Debug build. With a Release build the output was "clean". Regarding the third point, that was I concern that I also had, however, since the quit command also opened a window, I assumed that was the way to go. I was concerned that a patch "circumventing" this behavior would be too intrusive and not be accepted for a merge. But since we seem to agree on that, I will have another look regarding that direction. Do you have already something in mind? If not, I would just start digging a little further when I have some more time to spare to come to a solution.

Ah yes true, on macOS and Windows release builds, we will redirect the normal error logging to a log file so it won't be printed to the console. I was testing on Linux which prints the output to the terminal.

We can probably use the same state machine and stuff, just printing progress messages to the console instead of using a window.

I have made the changes, but I am not sure if that is what you had in mind. Let me know what you think.

Thanks, I'll take a look once I'm back from vacation

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

update on this?

Rebased and merged manually to resolve conflicts:

de881769950bf34ed8af6ba8786dcfe378452f6d 0802609fd88341f37c34d197b0a6d569881a18cf 4ee36fd405f382315a494ac8464fb59aa5c44403