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 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
