Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DolphinQT: Gives option to add desktop shortcut #9438

Merged
merged 1 commit into from Jan 27, 2021

Conversation

shuffle2
Copy link
Contributor

When a game is selected, the option to add a shortcut of the game to the desktop is given. Uses native Windows API since Qt lacks support for adding shortcuts.

This is a modification of #9365 , using WIL and handling all error/memory leak cases correctly (hopefully 🙂)

When a game is selected, the option to add a shortcut of the game to the desktop is given. Uses native Windows API since Qt lacks support for adding shortcuts.
#ifdef _WIN32
bool GameList::AddShortcutToDesktop()
{
auto init = wil::CoInitializeEx_failfast(COINIT_APARTMENTTHREADED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if failfast is desirable here - COM may already be initialized in a different threading model, and I don't think this code must use an apartment threaded model?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is (I think?) the only wrapper provided by WIL. Multithreaded would not work here as it's on a GUI thread. Specifying multithreaded resulted in an assert, so I think it's working as intended? However, I didn't investigate further to find out what is calling CoInitialize on this thread beforehand.

All CoInitialize* calls on a specific thread should specify the same threading model, even though it's possible to specify multiple threading models (and ignore the returned error code). I think it's better to be explicit about the expectation (which is probably why WIL only exposes a _failfast version of the API).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible - but if you don't want to make a strong assumption like this, you could. My WASAPI PR realizes this by calling CoInitializeEx "manually" and then activating/deactivating the RAII CoUnitialize call basing on the result.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed cubeb has something similar. I'd rather use what's provided by WIL, and I don't think making a strong assumption is a problem here. Ideally, all usages of CoInitialize would make strong assumptions (therefor if they trigger fastfail, it's a good indication some code is actually being used incorrectly).
If you want to make a wrapper like cubeb's, maybe consider moving it to some more common location in dolphin?

@leoetlino
Copy link
Member

ah, this looks much nicer than the non-WIL version!

@leoetlino leoetlino merged commit 6dc0f0d into dolphin-emu:master Jan 27, 2021
10 checks passed
@shuffle2 shuffle2 deleted the add-shortcut-to-desktop branch January 27, 2021 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants