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

[Fedor Lyakhov]

Hi everyone,

I've made a bit of progress on this issue - "disable wallpaper" and
"disable animations" somewhat work with Gnome3. The code is very simple:

static void disable_animation()
{
    GSettings *desktop_settings =
g_settings_new("org.gnome.desktop.interface");
    g_settings_set_boolean(desktop_settings, "enable-animations", FALSE);
}

static void disable_wallpaper()
{
    GSettings *desktop_settings =
g_settings_new("org.gnome.desktop.background");
    g_settings_set_boolean(desktop_settings, "draw-background", FALSE);
}

But looks like this isn't enough. This implementation of disable_wallpaper
actually freezes current background, it is still displayed just isn't
scaled properly when e.g. resolution changes. I'd love some input from
anyone with Gnome3 knowledge... What's expected behavior for Spice client
in this case?

Disable_animations seems to not changing things much - at least I still see
some animations when opening menu or pressing Action button (top left
corner).

Another question is about --spice-disable-effects=font-smooth. While this
can be changed via GSettings, I think it should be changed at X level,
correct? Leading to subsequent question of supporting Wayland/Weston...
Also I don't really see any use case for disabling anti-aliasing... Maybe
configuring anti-aliasing level makes sense...

Next question is about --spice-color-depth. Right now it supports
Windows-specific values of 16 and 32, for Linux we'd need to support 16 and
24. I think this setting should be adjusted at X level, similarly to
anti-aliasing.

There is another level of complexity: changing these settings takes
permanent effect, and user doesn't have any means to reset them except
dconf-editor (not user friendly at all).
So looks like we'd need an '--spice-enable-effects' option (and by default,
when enable/disable isn't set, use local-only detection - to be
implemented). What do you think?

And finally, I haven't looked into KDE settings counterpart yet, but the
question is already here - how should we bind to KDE settings API. Late
binding via dlopen/dlsym - to be used only if KDE detected? Also,
GSettings/Gnome3 support relies on GIO - and currently vdagent isn't
dependent on this library (only on GLib). Should we not favor Gnome3 over
KDE here and implement this feature symmetrically?

I'm really sorry for so much questions about this tiny feature...
Implementing DE-specifics within a client doesn't seem so easy or proper
way for me now...




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

> Hi,
>
>
> On 07/05/2013 06:07 PM, Fedor Lyakhov wrote:
>
>> 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.
>>
>
> Good.
>
>
>  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.
>>
>
> And they do, the suggestion to use the system dbus was related to your
> proposal where the agent would advertise
> settings and the session(s) settings manager would query them. If you
> follow my proposal the agent will be
> actively making the changes, and that certainly belongs in the session
> part of the agent.
>
>
>  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...
>>
>
> Correct, but if the session's settings manager will query the agent (the
> old design) there is no need to know
> the session type.
>
>
>  Also how this will work when Spice supports multiple client connections
>> to one guest?
>>
>
> A good question, this is something which is best left for later.
>
>
>  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).
>>
>
> I would prefer 1. You could also do 2 in parallel as a proof of concept,
> when starting
> a discussion about a unified dbus API for this, it helps to have some
> example code, but I
> believe that to get results quickly we should do 1 (we can still pursue 2
> in parallel to
> work to a better solution in the future).
>
> Regards,
>
> Hans
>



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