5:16 a.m.
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
8:44 p.m.
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(a)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
4:33 a.m.
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(a)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 :|
6:24 a.m.
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
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
6:50 a.m.
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 :|
8:04 a.m.
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
5595
days inactive
5602
days old
5 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Guido Günther