Thanks for the answer, Marc-André! Few comments inline. On Tue, Jul 23, 2013 at 4:27 PM, Marc-André Lureau <marcandre.lureau@xxxxxxxxx> wrote: > > Hi > > On Mon, Jul 22, 2013 at 10:28 PM, Fedor Lyakhov <fedor.lyakhov@xxxxxxxxx> 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel