[Spice-devel] Questions regarding Bug 62033 - Means to detect local-only

[Hans de Goede]

Hi,

On 07/05/2013 03:08 PM, Marc-André Lureau wrote:
> hi
>
> On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov <fedor.lyakhov at gmail.com> wrote:
>> Hello everyone,
>>
>> I continue working on this "bug62033 means to detect local only" issue, and
>> want to confirm whether I'm going in the right direction so the result can
>> be committed into Spice.
>> My plan is:
>> 1. Announce capability of DisplayConfig by vdagentd, then receive
>> VDAgentDisplayConfig message in vdagentd (set via --spice-disable-effects
>> and --spice-color-depth for client), send it to vdagent (via new udscs
>> message). [Done]
>> 2. Use current GLib/GIO bindings for DBus in vdagent:
>> a) add new thread for GLib loop [In Progress]
>> b) take ownership of 'com.redhat.spice.vdagent' name at session bus [Done]
>> c) provide signals: effects_changed, color_depth_changed (need better names
>> and signatures - maybe we should split wallpaper, animation and font smooth
>> here...)
>
> Instead of forwarding the event to the session via udscs and then
> emiting signal, I would use a dbus at system level and emit those dbus
> property change from there (not signals).

ACK for using the system bus, if we use dbus at all, see below.

>> d) provide interface methods to complement signals: get_effects_state,
>> get_color_depth;
>> 3. Emit g_signals in handler of VDAgentDisplayConfig message
>> 4. Implement getters
>>
>> Guest desktop management software (e.g. gnome-settings-daemon) should be
>> able to subscribe to our signals and act accordingly - and also should be
>> able to request current values (I'm going to implement test app handling
>> these signals, and maybe even propose a patch for Gnome, and then
>> investigate KDE opportunities)
>>
>> Is it acceptable solution? Weak spot seems to be introduction of DBus via
>> GLib. While GLib is already linked by vdagent, it isn't used to full extent
>> (i.e. there is no GLib loop); also DBus bindings are available via libgio -
>> a new dependency; and this will work with GLib&GIO 2.26+ (current dependency
>> is 2.12 afaik).

I seem to have missed the whole discussion deciding to make this a
spice-vdagent dbus interface. The agent is not offering a service here,
as typical dbus services are, instead it is offering information in the
hope others will pick it up. This feels the wrong way around.

To me, how this should work is like this:

1) spice-vdagentd forwards info to spice-vdagent in the X-session
2) spice-vdagent "connects" to the desktop environments settings daemon
and changes the settings (after which the settings daemon will notify
interested parties).

Yes this means having a per desktop-environment implementation for this
in spice-vdagent. But the current proposal does not avoid having to do
per desktop-environment work, it just moves that work to inside the
desktop-environment.

I believe getting spice specific patches accepted into the various
desktop environments, is going to be an uphill battle, and if we need
to write per de code anyways, it is best to keep it inside the agent,
were we at least have control over if and when to merge the code.


Now ideally there would be a generic dbus interface for all this, so
that it can be used for example by the vmware linux agent, vnc / rdp
agents, etc. too. I suggest working on creating a standard interface
for this under the freedesktop.org umbrella. And in the mean time
simply add de specific code to the X-session spice-vdagent to forward
these settings in a de specific manner.

Then once we've a standard we can slowly mover over to that.

IMHO creating a spice-specific interface for this, is not acceptable,
it is not generic enough to warrant the effort of teaching all
desktop-environments about it.

> Unfortunately I think Hans would prefer to avoid glib/gio usage in
> spice-vdagent...

Since the addition of file-xfer support the X-session agent already
uses glib.

>
> RHEL6 is updating to glib 2.26, we should be able to bump dep without issue.
>
>> I considered using dbus-1-glib bindings, but they're marked as obsolete at
>> DBus website, so we shouldn't use them for new code...
>
> Let's avoid dbus-1-glib ;)

+1

Regards,

Hans