Closed taoso closed 8 years ago
LEW21
commented
8 years ago Currenty it does not, as exporting interfaces was impossible for a long time because of https://bugzilla.gnome.org/show_bug.cgi?id=656325
Now there aren't any blockers any longer, but still a new API would have to be created for it, and I don't currently have time for doing it.
bewest
commented
8 years ago I know you're busy, I've been banging my head against this for several weeks and in the meantime have found about a dozen similarly affected people.
The bug you linked to isn't yours per se, but seems very related to https://bugzilla.gnome.org/show_bug.cgi?id=656325, and I'm wondering how to proceed. The bug you linked to was the last blocker.
The frustrating thing (not your fault) is that I've been told "use gdbus" but I have not managed to piece together a working python dbus server afflicted by some bug in some way. This comment from the previous thread is especially frustrating after being told to "use gdbus" myself:
Interesting fact: GDBus was never intended to be bindable - the idea was always that languages would provide their own D-Bus bindings based on libdbus-1. That was the thinking at the time GDBus was designed. And the main reason that GVariant was used (as GVariant wasn't designed to be bound either, IIRC.. at least not without a lot of work.) It's more an accident that mostly everything is easily bindable..
Again, not your fault, but I wanted to link these things together in some way, any further details/folk-lore you can add would be welcome. The especially annoying thing is that some of these issues date to 2011, I guess that's when the focus from desktop to mobile really really shifted.
My analysis: in general, the new-style gtk3/Gio/Glib bindings were heavily designed around desktop use, while interest shifted to mobile and internet of things. In particular, the only reason I can't use the older python-dbus is because the mainloop will coalesce and duplicate events if you attempt to create new loops in temporarily lived background threads. Meanwhle subclassing from Gtk.Application works fantastic unless you didn't want or need a GUI, and really just wanted dbus/webosckets/IPC.
Other considered sources, for note taking:
Currently, I have no idea when the bug fixes mentioned above are likely to be shipped by distros; in the meantime, python segfaults or errors randomly when trying test scripts using register_object.
Anyway, thanks again for the wonderful library. If you still have any connection with some of the other authors involved, I'd love to understand the next needed steps better.
LEW21
commented
8 years ago Thanks for linking hello-dbus, it looks cool.
I've just tested it, the bug I linked is fixed in glib 2.46 (or 2.45, but I think that no distribution has 2.45 packaged). It's available in ArchLinux, Manjaro, Debian Stretch, Ubuntu 16.04, Fedora 23, openSUSE Tumbleweed.
bossjones
commented
8 years ago Also you can use Ubuntu 15.10 and add the following PPAs to help you get the versions you need:
https://launchpad.net/~ricotz/+archive/ubuntu/testing https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3 https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging
Package versions needed to prevent segmentation faults:
gobject-introspection 1.46.0
Python-gi 3.18.2
Pydbus 0.3
glib-networking:amd64 2.46.0-1
glib-networking-common 2.46.0-1
glib-networking-dbg 2.46.0-1
glib-networking-services 2.46.0-1@bewest I forgot that I hadn't created a PR in my ansible repo, https://github.com/bossjones/scarlett-ansible/pull/2 w/ all of the 15.10 fixes I made to get things working. Maybe I'll break this out and make it into an ansible playbook responsible for provisioning any stand alone gnome + python development environment to help others. Ill do that this week, shouldn't be difficult since I basically have the steps in the PR above, just need to make it standalone.
Does pydbus has any alternative for the
dbus.service.Object?