Windows Support

[gosselind1]

Though there used to be some notes about windows support a while back, it seems that this is no longer the case.

I've taken the liberty to get the application to a working state, though there's probably a fair bit of clean-up.

Unlike one of the more recent windows tickets #668 I have targeted windows support via msys2, which should give it much more "close to native" performance, at the potential overhead of a fair bit of package bloat.

In order to get it working in my msys2 environment, I additionally implemented the suggested solution for secrets as suggested in #559. One of the concerns of adopting the secrets library in that ticket is transitioning the project to using a singular file store instead of a wallet or analogous piece of software. However, in its current form, the linked library supports said functionality.

I have some additional error clean up to do, but pithos now works for audio playback in windows with an overhaul of the secrets library in the util.py file.

Would the project be open to PRs for this?

[TingPing]

I could be open to different password storage on Windows.

If you could make it a shared interface so we have a backend for windows and a backend for libsecret.

[gosselind1]

Hmmm. Okay, I figured using secrets would be much simpler than re-implementing logic on a per-platform basis. I'll have to think through this a bit more. Regardless, this is my patched util file at the moment:

https://github.com/gosselind1/pithos/blob/keyring-experiment/pithos/util.py
(edit-- shuffled around the branch name)

[TingPing]

While I like the idea of just using a single library, I don't think keyring is a good library.

• Depends on deprecated python-dbus
• All APIs do blocking IO
• Unreliable backend choices, like if a user has a problem first we have to debug which backend it even uses

(I'd also be curious to test it inside of flatpak to ensure it works there)

In the end I think it is easier and higher quality to abstract it inside of Pithos.

[gosselind1]

Good points. After a bit of thought and review of some things:

• python-dbus seems to be only be used in conjunction with kwallet, though this then loops to point three. (I haven't dug specifically through all the backends though, so the high-level documentation could be wrong here).
• Unless I misunderstood something, the flatpack code paths are synchronous which would make those paths blocking.
• Also a very fair point. I think its technically possible to actually disable backends on-demand with keyring, though this seems to be encroaching on the dirty hacks territory.

(I haven't checked this, though when I get some time I'll check this for posterity)

After thinking about this for a bit, I think one approach might be to have "server" object available for querying on a separate multiprocessing process. The actual object could then be implemented as a secret provider class which follow from some common abstract base class (ABC) (or some simple base class if simplicity is desired). The base class would then enable different platform implementations.

I would need to do some additional digging to determine how the current secrets1 library handles its async call backs to implement in a similarish mechanism such that the existing code is compatible though. Not sure how much digging needs to be done there.

[TingPing]

Unless I misunderstood something, the flatpack code paths are synchronous which would make those paths blocking.

There is a single blocking call to Secret.password_lookup_sync() which is working around a libsecret bug. Otherwise everything else is async.

As for how to wrap a blocking API; It is possible to use the threading module you just have to use GLib's APIs to schedule the callback when its done. You can see the pithos/gobject_worker.py file to see how Pithos does this.

[gosselind1]

As the above commit is getting ready for merge, I want to document some additional issues I am aware of, and other odds and ends.

Issues:

1. The cache directory is not working due to targeting a linux path. -- This is a simple fix and I already have it in another branch
2. Notifications are non-functional. -- See: https://gitlab.gnome.org/GNOME/glib/-/issues/1234
3. Windows gives pithos a python terminal icon. -- Need to dig to see if this can be change during run-time, or if this requires some Windows specific magic. I tried some things, but I haven't had much luck yet.
4. Application requires a terminal to launch. -- This one most certainly requires windows magic, but might be a bird with two stones in relation to 3.
5. Lots of plugins are broken and or not applicable to windows. Hotkeys, minimization to tray, anti-screen saver, etc

Others:

1. I am close to a decent pkgbuild for msys2, but would also like to produce a build script that is based around gvsbuild, per gtk's documentation, as that appears to be the more "native" option. https://www.gtk.org/docs/installations/windows
2. In writing the secrets code up I had to employ a work-around due to a missing library function in pywin32. While I did document it, its still annoying and I'd rather remove the work-around. This of course means implementing that function. CredGetSessionTypes is not implemented in win32credmodule.cpp mhammond/pywin32#2067
3. I noticed that there was an automated build test-script for flatpack added. Would it make sense to produce a windows specific one, using the more native gvsbuild configuration?
4. The audio stuttering / glitches that are mentioned in a few other issues are also present in the windows specific builds.

[TingPing]

Windows gives pithos a python terminal icon. -- Need to dig to see if this can be change during run-time, or if this requires some Windows specific magic. I tried some things, but I haven't had much luck yet.

Maybe Gtk.Window.set_icon()

[TingPing]

I noticed that there was an automated build test-script for flatpack added. Would it make sense to produce a windows specific one, using the more native gvsbuild configuration?

The question is just who is going to look at and maintain it.

Pithos itself doesn't really have tests and errors would be runtime ones. So unless you are regularly testing it I don't think it has value.