<div dir="ltr"><div><div><div><div><div><div><div>Thanks for your answers!<br><br></div>Looks like the issue is more complicated than I originally thought. But I'm still excited to continue working on it.<br></div>Ok, I'm going to follow Hans' view now.<br>
</div><br>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... <br>
Also how this will work when Spice supports multiple client connections to one guest?<br><br></div>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:<br>
</div>1. Implement DE-specific code within vdagent/vdagentd<br></div>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).<br>
</div><div></div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 5, 2013 at 5:22 PM, Hans de Goede <span dir="ltr"><<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div class="im"><br>
<br>
On 07/05/2013 03:08 PM, Marc-André Lureau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hi<br>
<br>
On Fri, Jul 5, 2013 at 2:40 PM, Fedor Lyakhov <<a href="mailto:fedor.lyakhov@gmail.com" target="_blank">fedor.lyakhov@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone,<br>
<br>
I continue working on this "bug62033 means to detect local only" issue, and<br>
want to confirm whether I'm going in the right direction so the result can<br>
be committed into Spice.<br>
My plan is:<br>
1. Announce capability of DisplayConfig by vdagentd, then receive<br>
VDAgentDisplayConfig message in vdagentd (set via --spice-disable-effects<br>
and --spice-color-depth for client), send it to vdagent (via new udscs<br>
message). [Done]<br>
2. Use current GLib/GIO bindings for DBus in vdagent:<br>
a) add new thread for GLib loop [In Progress]<br>
b) take ownership of 'com.redhat.spice.vdagent' name at session bus [Done]<br>
c) provide signals: effects_changed, color_depth_changed (need better names<br>
and signatures - maybe we should split wallpaper, animation and font smooth<br>
here...)<br>
</blockquote>
<br>
Instead of forwarding the event to the session via udscs and then<br>
emiting signal, I would use a dbus at system level and emit those dbus<br>
property change from there (not signals).<br>
</blockquote>
<br></div>
ACK for using the system bus, if we use dbus at all, see below.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
d) provide interface methods to complement signals: get_effects_state,<br>
get_color_depth;<br>
3. Emit g_signals in handler of VDAgentDisplayConfig message<br>
4. Implement getters<br>
<br>
Guest desktop management software (e.g. gnome-settings-daemon) should be<br>
able to subscribe to our signals and act accordingly - and also should be<br>
able to request current values (I'm going to implement test app handling<br>
these signals, and maybe even propose a patch for Gnome, and then<br>
investigate KDE opportunities)<br>
<br>
Is it acceptable solution? Weak spot seems to be introduction of DBus via<br>
GLib. While GLib is already linked by vdagent, it isn't used to full extent<br>
(i.e. there is no GLib loop); also DBus bindings are available via libgio -<br>
a new dependency; and this will work with GLib&GIO 2.26+ (current dependency<br>
is 2.12 afaik).<br>
</blockquote></blockquote>
<br></div>
I seem to have missed the whole discussion deciding to make this a<br>
spice-vdagent dbus interface. The agent is not offering a service here,<br>
as typical dbus services are, instead it is offering information in the<br>
hope others will pick it up. This feels the wrong way around.<br>
<br>
To me, how this should work is like this:<br>
<br>
1) spice-vdagentd forwards info to spice-vdagent in the X-session<br>
2) spice-vdagent "connects" to the desktop environments settings daemon<br>
and changes the settings (after which the settings daemon will notify<br>
interested parties).<br>
<br>
Yes this means having a per desktop-environment implementation for this<br>
in spice-vdagent. But the current proposal does not avoid having to do<br>
per desktop-environment work, it just moves that work to inside the<br>
desktop-environment.<br>
<br>
I believe getting spice specific patches accepted into the various<br>
desktop environments, is going to be an uphill battle, and if we need<br>
to write per de code anyways, it is best to keep it inside the agent,<br>
were we at least have control over if and when to merge the code.<br>
<br>
<br>
Now ideally there would be a generic dbus interface for all this, so<br>
that it can be used for example by the vmware linux agent, vnc / rdp<br>
agents, etc. too. I suggest working on creating a standard interface<br>
for this under the <a href="http://freedesktop.org" target="_blank">freedesktop.org</a> umbrella. And in the mean time<br>
simply add de specific code to the X-session spice-vdagent to forward<br>
these settings in a de specific manner.<br>
<br>
Then once we've a standard we can slowly mover over to that.<br>
<br>
IMHO creating a spice-specific interface for this, is not acceptable,<br>
it is not generic enough to warrant the effort of teaching all<br>
desktop-environments about it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unfortunately I think Hans would prefer to avoid glib/gio usage in<br>
spice-vdagent...<br>
</blockquote>
<br></div>
Since the addition of file-xfer support the X-session agent already<br>
uses glib.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
RHEL6 is updating to glib 2.26, we should be able to bump dep without issue.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I considered using dbus-1-glib bindings, but they're marked as obsolete at<br>
DBus website, so we shouldn't use them for new code...<br>
</blockquote>
<br>
Let's avoid dbus-1-glib ;)<br>
</blockquote>
<br></div>
+1<br>
<br>
Regards,<br>
<br>
Hans<br>
</blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Fedor
</div></div>