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

[Fedor Lyakhov]

Thanks for your answers!

Looks like the issue is more complicated than I originally thought. But I'm
still excited to continue working on it.
Ok, I'm going to follow Hans' view now.

One thing I don't understand: why would we want to apply these 'effects'
settings via vdagentd (system level)? For me they belong to session level.
Before the session is started there is no way for us to know will it be
Gnome or KDE or w/e - it is decided upon login...
Also how this will work when Spice supports multiple client connections to
one guest?

I'll investigate current ways of toggling 'effects' in Gnome and KDE - to
understand how far we are from common standard way for doing this. Assuming
there is no common way, what would you prefer:
1. Implement DE-specific code within vdagent/vdagentd
2. Introduce something like 'draft standard dbus interface for controlling
DE effects', and add sample Gnome and KDE implementations (which would hide
DE-specifics from vdagent).



On Fri, Jul 5, 2013 at 5:22 PM, Hans de Goede <hdegoede at redhat.com> wrote:

> 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
>



-- 
Best regards,
Fedor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130705/c54f06d2/attachment.html>