[Spice-devel] Bug62033 Add support for --spice-disable-effects client option to spice-vdagent on Linux guests with Gnome3

[Fedor Lyakhov]

Hans,

Thanks for such a quick reply! I agree with your comments. Thanks for
pointing to inhibitors interface - I wasn't aware of it, need to study
it and see what KDE (and Unity) have in place.


On Mon, Sep 16, 2013 at 11:34 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 09/15/2013 09:33 PM, Fedor Lyakhov wrote:
>>
>> Hello Hans,
>>
>> Finally I've found time to continue with this topic. Have sought for
>> better solution and only come to improved previous one.
>>
>> *Requirements*
>>
>>
>> Let's start with clarifying requirements.
>> req-1. As a user I want to have my desktop effect settings untouched if
>> connected under normal conditions.
>> req-2. As a user I want to have a few desktop effect settings disabled if
>> connected under bad conditions.
>> The list of settings shall be configurable (as of now - wallpaper,
>> animations, font smoothing) - if this isn't true in oVirt, I'd need work on
>> it as well, because disabling all of them may reduce user experience to
>> unacceptable level, resulting in feature becoming useless for many users.
>> Bad conditions can be identified by the user himself (via UI), or
>> automatically - to be implemented later.
>>
>> Both these stories taken together implicitly require:
>> req-3. After connecting under bad conditions and having effects disabled
>> and then connecting under good conditions, as a user I want my desktop
>> effect settings restored to their normal (previous) values.
>>
>> Non-functional requirements:
>> req-4. Robustness. Crash-proof solution: upon vdagent crash, qemu crash or
>> forced guest shutdown, correct state of effect settings must be restored for
>> next session.
>> req-5. Simplicity. KISS, "Choose simplest possible implementation".
>>
>> DEs to support:
>> req-6. Main: Gnome3, KDE4, Unity; Stretch goal: XFce, LXDE
>>
>> digression {
>> Or do we need to talk about Window Managers here? Or display servers?
>> req-7. Solution shall be display server agnostic (X.Org, Wayland, XMir,
>> Mir...).
>> req-8. Solution shall be window manager/shell agnostic (Mutter/Gnome
>> Shell, KWin/Plasma, Compiz/Unity, Cinnamon probably - if we even bother of
>> Ubutu, why don't respect Mint... etc).
>>
>> Seems my lack of expertise in display system stacks in Linux is blocking
>> me here; probably solution cannot be fully WM/shell agnostic. I'm going to
>> try using DE abstraction level over WM specifics... if this makes sense.
>>
>> All this profusion of DE/WM/Display servers nowadays results in a fact
>> that without some standard implemented by them, it won't be possible to
>> support all of them (and EWMH isn't even near the level of required
>> interop...).
>> }
>>
>> I know you'd like to weaken functional requirements if higher simplicity
>> is possible. Could you please try specifying these weakened requirements - I
>> cannot think up them myself.
>
>
> My main reasons for weakening the functional requirements are not
> simplicity,
> but keeping things in out own hand. IOW do this without making changes
> outside
> of spice components.
>
> However now that this has had some time to settle, I think that it is best
> to not
> weaken the requirements, but instead do this right (which will likely turn
> out
> simpler then trying to use existing API-s in ways they were not really
> intended).
>
>
>> Given the fact there are so many different display systems in Linux, it
>> isn't practically possible to support all of them. On the other hand,
>> supporting only few and not providing any means for developers of other
>> systems to add similar support themselves doesn't make sense to me. So I
>> suggest following architecture:
>> <vdagent> --DBus-- <DE-specific display effects daemon> -- <DE API for
>> effects>
>> Basically vdagent (session, not system one) is to use DBus interface for
>> toggling effects. The feature will be available only if the interface is
>> implemented in the system.
>
>
> Agreed.
>
>
>> And this implementation should be DE-specific and maybe even part of DE.
>> But as we (Spice) are concerned with major DEs, sample implementation will
>> be provided for Gnome3, KDE4 and Unity.
>
>
> More likely patches will provided for, as this will likely be part of
> existing code in the DE.
> Could be you already meant to say as much, just making sure, that this
> sample implementation
> will not necessarily be a standalone thing.
>
>
>> Eventually I'm going to open tickets for these systems to include the new
>> DBus interface implementation in their systems (like gnome-desktop-daemon).
>> This should generate a good feedback upon interface itself (i.e. need to
>> create an
>> interface acceptable for all these DEs).
>>
>> Interface (subject to renames):
>>
>> bool SetMinimumDesktopBackground() // if already minimum, do nothing; save
>> current desktop background settings; set solid background, saved color (if
>> none, use default)
>> bool RestoreDesktopBackground() // if nothing is saved, do nothing; if
>> solid desktop background, save the color; restore desktop background
>> settings
>>
>> bool SetMinimumFontSmooth() // if already minimum, do nothing; save
>> current font smoothing settings; set antialiasing and hinting to the minimum
>> yet acceptable level
>> bool RestoreFontSmooth() // if nothing is saved, do nothing; restore font
>> smoothing settings
>>
>> bool SetMinimumAnimations() // if already minimum, do nothing; save
>> current animation settings; disable all decorative window animation effects,
>> but keep meaningful animations like spinnings enabled (if possible)
>> bool RestoreAnimations() // if nothing is saved, do nothing; restore
>> animation settings
>
>
> I think it would be best to make this part of the existing inhibitors
> interface, so you would
> get inhibitors for animation fontsmooth and desktopbackground.
>
> At least from the gnome pov doing things this way makes a lot of sense,
> problem is that the
> current gnome inhibitors interface is somewhat gnome specific AFAIK. It
> would be interesting
> to try and turn it into an fdo standard, esp. since spice already uses it
> for other things
> (inhibit automounting when usb auto-redirect is active).
>
> Note that the inhibitors interface is very much like what you already
> suggested, but it
> adds additional crash protection, automatically doing RestoreFoo() on agent
> crash.
>
>
>> To satisfy functional requirements, vdagent is going to use the interface
>> in following way:
>> 1. If received VDAgentDisplayConfig with flag to disable an effect, call
>> appropriate SetMinimumXXX()
>> 2. If received VDAgentDisplayConfig without flag for an effect, call
>> appropriate RestoreXXX()
>> One of these is always executed upon user's re-connect (unless failures in
>> other system parts prevent delivery of VDAgentDisplayConfig message).
>> This is the same logic VDAgent for Windows is following currently.
>>
>> This approach makes the implementation in vdagent very simple and
>> stateless. All effects managing logic is moved to DE-specific module.
>> Robustness of vdagent is achieved as it is stateless and crashes can affect
>> only current session. After vdagent restart (e.g. user re-login), correct
>> state will be restored.
>
>
> Yes, I like.
>
> Regards,
>
> Hans



-- 
Best regards,
Fedor