Re: Questions regarding Bug 62033 - Means to detect local-only

[Fedor Lyakhov <fedor.lyakhov@xxxxxxxxx>]

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

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel