Add support for linking existing Non-Steam shortcuts

[Maz111111]

Implements the functionality discussed in #120 and also addresses the use case reported in #149.

Summary

This adds support for linking an existing Non-Steam shortcut to a GameStream host app.

The existing Non-Steam shortcut remains the single visible library entry:

• Normal Play continues to launch the local shortcut.
• The MoonDeck button launches the linked host app.
• MoonDeck does not need to create a second visible library entry for the linked app.

Links can be created and changed from the MoonDeck launch button and managed from a new Linked Non-Steam Apps settings page, where they can also be changed or removed.

Implementation

The implementation keeps the visible source shortcut separate from the technical shortcut used for the MoonDeck launch.

A hidden GameStream helper shortcut stores the link to the source Non-Steam shortcut. These helper shortcuts are also used to reconstruct the mappings when MoonDeck initializes.

This avoids adding a new settings schema or backend persistence format for the links.

Linked helper shortcuts are excluded from the normal external-app shortcut management so that they do not appear as duplicate visible entries.

Launch handling keeps both identities available:

• the visible source app, used for the library page and source-app state;
• the technical runner/helper app, used for the streamed launch.

This also ensures that navigation returns to the original visible shortcut after launching.

UI

A new full settings page is added:

GameStream Apps → Linked Non-Steam Apps → Non-Steam Apps

The page shows the existing links and allows:

• changing a link;
• unlinking an app;
• confirming or cancelling unlink operations.

Link management is intentionally kept out of the Quick Access menu.

Testing

I manually tested the following behavior:

• linking an existing Non-Steam shortcut;
• restoring the link after initialization/restart;
• streamed launch through the MoonDeck button;
• normal local launch through Steam Play;
• multiple linked shortcuts;
• changing an existing link;
• unlinking and relinking;
• no duplicate visible library entries;
• navigation back to the visible source shortcut after launch;
• existing standard MoonDeck/Steam app behavior;
• full reboot/restart persistence.

The frontend also passes ESLint and the Rollup build.

I am opening this as a draft because the implementation touches shortcut identity and launch handling, and I would particularly appreciate feedback on the architecture before doing broader testing.

Development transparency

This contribution was developed with substantial assistance from AI tools.

I am not a software developer and do not claim programming expertise. I defined the desired behavior, performed the builds and deployments, and manually tested the resulting functionality on my own systems. The implementation itself was developed with AI assistance and should be reviewed accordingly.

The complete source code is provided so that users and maintainers can inspect the implementation before deciding whether to run it on their systems.

[FrogTheFrog]

Here's what I think.

This solution is incomplete and does not handle the case (yet) when you have Steam, Non-Steam and GameStream shortcuts all referring to the same game. In this case we would need the Steam game to nave N+ buttons for all Non-Steam and GameStream apps.
Even if we stay with the current approach, I don't like that you manually have to link shortcuts and store such information in a completely new shortcut. Existing shortcuts could be reused to store data to where it is linked to.
Also, there should be some sort of "auto-link" button based on game names perhaps.

As you have mentioned, the AI tooling was used extensively, which will cause complications getting this approved for the Decky store. For this reason alone, I'm not sure if I can accept such a PR.

I know I said:

I'm going to close this as I don't see myself investing time into this. If someone else want, feel free to open PR.

But the more I think about the complexity it brings vs. the benefit you get out of this, the more doubts about all of this I have.

[FrogTheFrog]

With all of that said, your approach gave me an idea that I want to try out. Maybe this can be done after all. No promises, but I will try something out when I have time.

[Maz111111]

Thanks for taking the time to think this through.

Seeing the related request also made me think that this might not be quite as niche a use case as I first assumed, which is what made me curious enough to try it.

I also genuinely had a lot of fun with the experiment itself. Part of the motivation for me was simply to see how far I could get as a non-developer using AI assistance, and for me this PR was also a proof of concept that I could get something from an idea to a build that actually works and that I could test on my own setup.

I completely understand your concerns about the added complexity and the Decky implications. I’ll leave the PR as it is for now and won’t push further changes while you explore your idea.

If it is useful later, I’d be very happy to test what you come up with, provide feedback, or adapt this branch if there is a specific direction you would like me to try.

Thanks again for taking a look at it.