[libvirt] [PATCH] libvirt-glib: add missing details argument to callbacks
Hi, the python example is lacking the details argument in the callback. This makes the example fail due to the wrong number of arguments. Cheers, -- Guido
On Wed, Jul 22, 2009 at 12:16:27PM +0200, Guido Günther wrote:
Hi, the python example is lacking the details argument in the callback. This makes the example fail due to the wrong number of arguments. Cheers, -- Guido
From: =?utf-8?q?Guido=20G=C3=BCnther?= <agx@sigxcpu.org> Date: Wed, 22 Jul 2009 12:01:36 +0200 Subject: [PATCH] add missing details argument
--- examples/event-test.py | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/event-test.py b/examples/event-test.py index bb8ed62..1c07b16 100644 --- a/examples/event-test.py +++ b/examples/event-test.py @@ -16,10 +16,10 @@ def eventToString(event): "Restored" ); return eventStrings[event];
-def myDomainEventCallback1 (conn, dom, event, opaque): +def myDomainEventCallback1 (conn, dom, event, detail, opaque): print "myDomainEventCallback1 EVENT: Domain %s(%s) %s" % (dom.name(), dom.ID(), eventToString(event))
-def myDomainEventCallback2 (conn, dom, event, opaque): +def myDomainEventCallback2 (conn, dom, event, detail, opaque): print "myDomainEventCallback2 EVENT: Domain %s(%s) %s" % (dom.name(), dom.ID(), eventToString(event)) Does this look o.k.? -- Guido
On Wed, Jul 29, 2009 at 03:44:07AM +0200, Guido G?nther wrote:
On Wed, Jul 22, 2009 at 12:16:27PM +0200, Guido Günther wrote:
Hi, the python example is lacking the details argument in the callback. This makes the example fail due to the wrong number of arguments. Cheers, -- Guido
From: =?utf-8?q?Guido=20G=C3=BCnther?= <agx@sigxcpu.org> Date: Wed, 22 Jul 2009 12:01:36 +0200 Subject: [PATCH] add missing details argument
--- examples/event-test.py | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/event-test.py b/examples/event-test.py index bb8ed62..1c07b16 100644 --- a/examples/event-test.py +++ b/examples/event-test.py @@ -16,10 +16,10 @@ def eventToString(event): "Restored" ); return eventStrings[event];
-def myDomainEventCallback1 (conn, dom, event, opaque): +def myDomainEventCallback1 (conn, dom, event, detail, opaque): print "myDomainEventCallback1 EVENT: Domain %s(%s) %s" % (dom.name(), dom.ID(), eventToString(event))
-def myDomainEventCallback2 (conn, dom, event, opaque): +def myDomainEventCallback2 (conn, dom, event, detail, opaque): print "myDomainEventCallback2 EVENT: Domain %s(%s) %s" % (dom.name(), dom.ID(), eventToString(event)) Does this look o.k.?
Yes, I'll apply it shortly. FYI, my libvirt-glib work is temporarily on hold due to lack of time. As such I've just pulled the event loop code directly into the virt-viewer application, so I can do a release of virt-viewer without needing to do a release of libvirt-glib right now. I want to pick it up again in the future and do something a little more advanced than just event loops, actually providing a proper GObject's for each libvirt objects so that GUI apps can just use normal GLib signal handling and properties, etc. virt-manager already does alot of this kind of wrapping in its own code, so its really pulling that out into a library where it can be shared Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
FYI, my libvirt-glib work is temporarily on hold due to lack of time. As such I've just pulled the event loop code directly into the virt-viewer application, so I can do a release of virt-viewer without needing to do a release of libvirt-glib right now. I want to pick it up again in the future and do something a little more advanced than just event loops, actually providing a proper GObject's for each libvirt objects so that GUI apps can just use normal GLib signal handling and properties, etc. virt-manager already does alot of this kind of wrapping in its own code, so its really pulling that out into a library where it can be shared Sounds great! Will the old API still be there? I've just uploaded
On Wed, Jul 29, 2009 at 10:33:12AM +0100, Daniel P. Berrange wrote: [..snip..] libvirt-glib into Debian: http://ftp-master.debian.org/new/libvirt-glib_0~0.git22fac-1.html and mentioned it in my talk at Debconf: http://honk.sigxcpu.org/projects/libvirt/libvirt-dc09.pdf Cheers, -- Guido
On Wed, Jul 29, 2009 at 01:24:24PM +0200, Guido G?nther wrote:
On Wed, Jul 29, 2009 at 10:33:12AM +0100, Daniel P. Berrange wrote: [..snip..]
FYI, my libvirt-glib work is temporarily on hold due to lack of time. As such I've just pulled the event loop code directly into the virt-viewer application, so I can do a release of virt-viewer without needing to do a release of libvirt-glib right now. I want to pick it up again in the future and do something a little more advanced than just event loops, actually providing a proper GObject's for each libvirt objects so that GUI apps can just use normal GLib signal handling and properties, etc. virt-manager already does alot of this kind of wrapping in its own code, so its really pulling that out into a library where it can be shared Sounds great! Will the old API still be there? I've just uploaded
It will almost certainly change. This is reason I've not done any release of libvirt-glib - i didn't want to commit to this API as it is. That said there's only one public symbol there so far. Could do some evil linker script black magic to add compatibility for that Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Wed, Jul 29, 2009 at 12:50:17PM +0100, Daniel P. Berrange wrote:
On Wed, Jul 29, 2009 at 01:24:24PM +0200, Guido G?nther wrote:
On Wed, Jul 29, 2009 at 10:33:12AM +0100, Daniel P. Berrange wrote: [..snip..]
FYI, my libvirt-glib work is temporarily on hold due to lack of time. As such I've just pulled the event loop code directly into the virt-viewer application, so I can do a release of virt-viewer without needing to do a release of libvirt-glib right now. I want to pick it up again in the future and do something a little more advanced than just event loops, actually providing a proper GObject's for each libvirt objects so that GUI apps can just use normal GLib signal handling and properties, etc. virt-manager already does alot of this kind of wrapping in its own code, so its really pulling that out into a library where it can be shared Sounds great! Will the old API still be there? I've just uploaded
It will almost certainly change. This is reason I've not done any release of libvirt-glib - i didn't want to commit to this API as it is. That said there's only one public symbol there so far. Could do some evil linker script black magic to add compatibility for that O.k. I'll keep it in experimental than so it won't end up in any stable release. Thanks for the update, -- Guido
participants (2)
-
Daniel P. Berrange -
Guido Günther