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

desktop/game_mode: Use i32 for pid #234

Merged
merged 4 commits into from
Sep 15, 2024

Conversation

kjarosh
Copy link
Contributor

@kjarosh kjarosh commented Sep 14, 2024

As per the documentation, methods which accept pids (e.g. RegisterGame, RegisterGameByPid) require the type of pid to be i (i32), not u (u32).

Using u32 causes errors in runtime, making these methods unusable. This bug was most likely introduced by ae81250.

See https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.GameMode.html

@@ -154,7 +154,7 @@ impl<'a> GameMode<'a> {
/// See also [`RegisterGame`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.GameMode.html#org-freedesktop-portal-gamemode-registergame).
#[doc(alias = "RegisterGame")]
pub async fn register(&self, pid: u32) -> Result<(), Error> {
let status = self.0.call("RegisterGame", &(pid)).await?;
let status = self.0.call("RegisterGame", &(pid as i32)).await?;
Copy link
Owner

Choose a reason for hiding this comment

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

why not replace the function signature? is this in order to have a backportable variant?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Originally, I had two reasons not to change the signature:

  1. Backward compatibility, in order not to break code that already uses u32. (Now writing this I realized that probably no one uses it as it doesn't work...)
  2. Better interoperability with Rust, as Rust uses u32 for pids: https://doc.rust-lang.org/std/process/fn.id.html, https://doc.rust-lang.org/std/process/struct.Child.html#method.id

Copy link
Owner

Choose a reason for hiding this comment

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

Right, in such case I would add

// Matches the type used in std
pub type Pid = u32;

and pass that to the functions instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure thing, added the Pid type alias and replaced most pids in API. There are instances where u64 is used though, but I haven't touched them.

Let me know if that's what you meant.

The Pid type alias ensures that the proper type is used for pids (u32),
which is the same as used by std.
As per the documentation, methods which accept pids (e.g. RegisterGame,
RegisterGameByPid) require the type of pid to be i (i32), not u (u32).

Using u32 causes errors in runtime, making these methods unusable.
This bug was most likely introduced by ae81250.
Copy link
Owner

@bilelmoussaoui bilelmoussaoui left a comment

Choose a reason for hiding this comment

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

lgtm, thanks

@bilelmoussaoui bilelmoussaoui merged commit 53e1c9b into bilelmoussaoui:master Sep 15, 2024
10 checks passed
@kjarosh kjarosh deleted the gamemode-pid-i32 branch September 15, 2024 20:39
@torokati44
Copy link

Do you think we could get a release on crates.io with this fix sometime soon?

@bilelmoussaoui
Copy link
Owner

Do you think we could get a release on crates.io with this fix sometime soon?

sure, later this week

@torokati44
Copy link

Great, thanks!

@torokati44
Copy link

(a polite bump on this 😶 )

@bilelmoussaoui
Copy link
Owner

ah, sorry, completely forgot about it. let me do a release now

@torokati44
Copy link

No worries, thanks a lot!

@bilelmoussaoui
Copy link
Owner

0.9.2 should be up

@torokati44
Copy link

Awesome, that was quick! ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants