-
Notifications
You must be signed in to change notification settings - Fork 3
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
AppletManager doesn't know what to do when a D-Bus call fails #7
Comments
We can probably make use of the |
This isn't totally fixed -- there are still errors occuring during a crash or kill of an applet:
|
I managed to fix the above traceback by adding some try..except code around the _removeActiveApplet code, but it's still not ideal. If the applet crashes or dies out, it can sometimes cross the DBus IPC barrier and kill the manager thread, or just stall out the applet UI (since the manager doesn't auto-unpresent when an applet crashes out). |
Right now the
AppletManager
is pretty rough, and has no idea what to do and simply dumps an exception when one of the following happens:At the moment, this is okay-ish since we're still pre-alpha code, but obviously it's not ideal. We need some way of tracking the applet peers on D-Bus. Maybe something like this:
com.theonelab.g13.Applet
under the path/com/theonelab/g13/Applet/AppletName
AppletManager
uses the list of objects under/com/theonelab/g13/Applet/...
as it's literal dictionary of applets available every single time it needs to do something with one. IOW, it polls D-Bus for applets and does a loose mapping between applet object name and its internal list of "registered applets".This would reduce some of the sources of the above two problems, but ultimately, I think we need lots of exception handling written around D-Bus proxies. Maybe a new class that wraps
dbus.proxy.ObjectProxy
to handle these things more gracefully?The text was updated successfully, but these errors were encountered: