[Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects

[Fedor Lyakhov]

OK, got it. Thanks for your patience. I'll CC you once the patch is ready...

I understand reasons behind both of the approaches - this one is
simple. But I'd need to add Spice vdagent D-Bus API for exactly this
one use case... hope that more interface functions will need to be
exposed in future.

Also this approach won't make the
"--spice-disable-effects=<wallpaper,font-smooth,animation,all>" option
to work (and implementing it using just gio's gsettings interface
looks unreliable... that's why inhibitor-styled API was proposed
actually). But we can live without it.

On Thu, Nov 7, 2013 at 10:32 PM, Bastien Nocera <hadess at hadess.net> wrote:
> On Thu, 2013-11-07 at 22:25 +0400, Fedor Lyakhov wrote:
>> Hi Bastein,
>>
>> On Mon, Nov 4, 2013 at 4:27 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>> > Hi,
>> >
>> >
>> > On 11/02/2013 05:50 PM, Fedor Lyakhov wrote:
>> >>
>> >> Bastein, Hans,
>> >>
>> >> We need an agreement on this topic so I can implement something - and
>> >> have it accepted in both Spice and Gnome eventually.
>> >>
>> >> There are 2 possible approaches conflicting here:
>> >> (i) (spice-proposed) DEs to export API for toggling effects
>> >> (preferable inhibitor-styled). Spice to actively use this API as it
>> >> sees fit.
>> >> (ii) (gnome-proposed) Spice to export API about its internal state,
>> >> DEs to recognize Spice and use that API as they want (e.g. disable
>> >> effects).
>> >>
>> >> Both approaches can work, and second one seems to be easier to
>> >> implement for Spice/Gnome stack.
>> >> Main arguments pro (i):
>> >> 1. It seems right for Spice to be in an active position, deciding what
>> >> to do. DEs are merely environments providing APIs and means for
>> >> applications to achieve their goals.
>> >> 2. Spice aims to support many DEs, not only Gnome (mainly under
>> >> freedesktop, ofc). Making other DEs to recognize Spice usage and
>> >> implement appropriate logic seems to be incorrect approach, which may
>> >> be not acceptable from their PoV.
>> >>
>> >> To address Bastein's concern about new inhibitors: we want them to be
>> >> system ones, similar to existing idle and other inhibitors. Not
>> >> something in the user space of Spice. They should be useful for other
>> >> remoting applications like VNC, and maybe some other apps (cannot
>> >> think up other real use cases right now).
>> >
>> >
>> > Either way works for me, with a slight preferences for having inhibitors.
>> >
>> > Regards,
>> >
>> > Hans
>>
>> Bastein, how much are you against Spice-proposed approach? If I can
>> reduce your concerns, I'm willing to do so...
>
> I'm not interested in adding a layer of "inhibitors" on top of something
> that supposed to be simple. As long as I have something that exports the
> whether or not SPICE is being used and/or too slow, I can implement the
> necessary code in gnome-settings-daemon.
>
> FWIW, this is the API that g-s-d uses for VNC connections, when Vino is
> used:
> $ gdbus introspect --session --dest org.gnome.Vino --object-path /org/gnome/vino/screens/0
> <snip>
>   interface org.gnome.VinoScreen {
>     methods:
>     signals:
>     properties:
>       readonly s ExternalHost = '';
>       readonly q ExternalPort = 0;
>       readonly s AvahiHost = 'nuvo.local';
>       readonly s Host = '192.168.0.14';
>       readonly q Port = 5900;
>       readonly b Connected = false;
>   };
> <snip>
>
> We just look at the "Connected" value. I'm looking for something
> just about as simple for Spice.
>
> Cheers
>



-- 
Best regards,
Fedor