[Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects
Fedor Lyakhov
fedor.lyakhov at gmail.com
Mon Dec 30 14:28:00 PST 2013
Hi all,
I've sent a preview patch of this work. Please confirm
1) the names of the bus, interface, object path
2) the interface itself (currently 3 read-only properties: Connected,
Type and Speed)
3) I'm not sure whether lazy generation of GDBusNodeInfo from
introspection XML (as static char *) is acceptable - or should I use
gdbus-codegen?
My next steps include:
1. Implement export of actual properties, i.e. connection status,
connection type (local/remote) and speed (in kbps). The idea is that
clients are expected to use Speed to judge upon disabling some
features like animations.
2. Implement signal on properties changed
3. Other TODOs (GIO 2.32 thread API change, error handling, doc & comments etc.)
On Mon, Dec 16, 2013 at 2:12 PM, Marc-André Lureau <mlureau at redhat.com> wrote:
> Hi
>
> ----- Original Message -----
>> Hi everyone,
>>
>> As we've decided a while ago (ITT), I'm looking into implementing a
>> DBus interface for spice-vdagent (session-level) using GDbus API from
>> GIO, and have run into following shortcomings:
>>
>> 1. vdagent is single-threaded and blocks on select() for udscs I/O
>> 2. vdagent isn't GLib-based
>>
>> A simplest solution I'm going to try first:
>> 1. Add GLib main loop in the vdagent main thread
>> 2. Create a separate GThread for all current I/O
>>
>> Will such change be acceptable?
>>
>> Next steps I can think of:
>> 1. Use GSource to attach current udscs I/O to GMainLoop
>> 2. Move most of current udscs messages to DBus - probably need to keep
>> using udscs for xfer for performance reasons.
>>
>> What do you think?
>
> Using GLib for main loop would be a good step forward.
>
> I am not sure using a separate thread for current IO is needed, but it might make it easier for a first step?
>
> thanks!
--
Best regards,
Fedor
More information about the Spice-devel
mailing list