Comments (8)
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.
from pithos.
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)
from pithos.
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.
from pithos.
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.
from pithos.
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.
from pithos.
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:
- 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
- Notifications are non-functional. -- See: https://gitlab.gnome.org/GNOME/glib/-/issues/1234
- 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.
- 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.
- Lots of plugins are broken and or not applicable to windows. Hotkeys, minimization to tray, anti-screen saver, etc
Others:
- 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
- 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. mhammond/pywin32#2067
- 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 audio stuttering / glitches that are mentioned in a few other issues are also present in the windows specific builds.
from pithos.
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()
from pithos.
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.
from pithos.
Related Issues (20)
- Only Quick Mix is available HOT 7
- Inhibit Screensaver doesn't work HOT 2
- SSL: CERTIFICATE_VERIFY_FAILED HOT 1
- org.gnome.Platform//40 is end-of-life HOT 1
- Cannot sign in to Pandora HOT 3
- Cannot start the app. Returns app/io.github.pithos/x86_64/master not installed HOT 4
- Song Change Notifications do not work in Flatpak version HOT 4
- Using pithos on linux phones HOT 6
- GStreamer 1.20 regression causes Pithos to stop playing after 1 or 2 songs HOT 46
- After viewing song info on several songs then the song timer stops and Pithos fails after that to advance songs HOT 8
- Feature Request: Filter explicit Content HOT 1
- Fresh Mint install. Pithos fails with "No secret collection at path:......." HOT 3
- Pithos cache grows without bound HOT 3
- RHEL-7 build dependencies HOT 1
- switch station from command line HOT 3
- Plugins not working (Python 3.11) HOT 7
- Shorter Tracks Labelled as Advertisements HOT 4
- flatpak install on chromeos - password lookup / pwd store both fail HOT 4
- TemporaryDirectory API used is too new for Debian (Bullseye)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pithos.