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

Fedor Lyakhov fedor.lyakhov at gmail.com
Wed Jul 24 13:07:47 PDT 2013


Thanks for the answer, Marc-André!

Few comments inline.


On Tue, Jul 23, 2013 at 4:27 PM, Marc-André Lureau
<marcandre.lureau at gmail.com> wrote:
>
> Hi
>
> On Mon, Jul 22, 2013 at 10:28 PM, Fedor Lyakhov <fedor.lyakhov at gmail.com> wrote:
> > 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?
>
> I think it is to have a solid background.

I see. Turns out this is not that easy to implement with Gnome3
settings, but looks like I've got somewhat acceptable behavior today.

>
>
> > 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).
>
> That doesn't surprise me. If you think that some shell animations are
> superflous, you may want to open a bug to GNOME.

Sarcasm?) Personally I find Gnome3 not practically useful, at least
3.6 in Fedora 18... But let's not dive into this holywar :)

>
> >
> > 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...
>
> There is a Antialias = None setting in gnome-tweek-tool, so there must
> be a corresponding GSettings key.

Yes, there is one, afaik accessible via xsettings plug-in for
gnome-settings-daemon... Will go this route.

>
> > 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.
>
> Apparently, this is not possible with randr & gnome, and might need a
> server restart. Also, I am not convinced this is the right approach,
> it would be nice to have actual numbers for different use cases..
>

Ok, I won't work on this topic for now. Probably you're right.

> > 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?
>
> Perhaps, although in general, you use your VM either over WAN or
> local, but not so much switching between the two all the time. And if
> it is the case, there are chances you prefer to have the same look and
> feel for both cases, so not doing any changes is probably ok.

I think that if we implement such intrusive behavior (changing
look&feel of DE), we should provide a user with similar means to
revert that...

> > 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 would say it's fine to link with kde low-level counterpart. But in
> general, favour DBus services usage if possible.

Ok, understood.

>
> > 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...
>
> Imho, you could win much more performance gains by getting back to
> "means to detect local only" and tuning spice settings itself
> (disabling image compression etc), not tweaking the desktop settings,
> but hey, do what you want! :)

Agree. I just don't feel too confident to dive in the internals now.
I'm trying to address Bug62033, but looks like Gnome/Boxes guys aren't
very interested in the solution now. It was their request for means to
detect 'spice local or remote' - that's why I started with DBus way in
the first place...

>
> --
> Marc-André Lureau


-- 
Best regards,
Fedor


More information about the Spice-devel mailing list