Protocol for window previews/thumbnails

[Mike Blumenkrantz]

On Thu, May 12, 2016 at 3:57 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 11 May 2016 23:35:01 +0100
> ade low <adloconwy at gmail.com> wrote:
>
> > Thank you for the feedback, that was very helpful.
> >
> > On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > >
> > >
> > > You should explain the use case behind the idea. Then it would be
> > > possible to assess whether such protocol would even be appropriate for
> > > it.
> > >
> >
> > My use case is third-party window switcher applications, such as
> > xfdashboard or my program, xfce4-lightdash-plugin:
> > https://github.com/adlocode/xfce4-lightdash-plugin
>
> The implementation of such things would have so much
> compositor-internal parts anyway, that making a protocol for it does
> not seem tractable to me. Why would anyone bother implementing such
> protocol in their compositor?
>
> > If some sort of protocol would be needed, then you have to figure out
> > > how to not make it a gaping security breach
> > >
> >
> > Perhaps the security could be improved by having a permissions system
> where
> > only authorised programs are allowed to use this protocol? Maybe the
> > compositor could expose a settings framework that allows the user to
> > control the permissions of applications.
>
> That is the hand-waving we have gone through several times before,
> without any solid and generic solution emerging yet. There are stabs at
> the issue, but nothing that is all of implemented, generic and widely
> accepted.
>
> The "there can be only one such client in a session" issue could be
> solved by the compositor launching the app with a pre-made,
> pre-authorized connection. That's how Weston does it.
>
> However, if instead of protocol, you'd have a plugin ABI in the
> compositor, that would be better on some aspects, but quite likely
> specific for each compositor. Supporting a generic plugin ABI falls
> down for many of the same reasons a standard protocol would.
>
> > A little more tractable plan would be to communicate only surface
> > > meta-data to the client, which could then ask the compositor to draw
> > > the thumbnails relative to one of the client's surfaces. The client
> > > would never have access to window content itself.
> >
> >
> > That's a good point; this could be a good solution, as long as it is
> > toolkit-independent and supports all rendering methods: OpenGL, pixman 2D
> > software rendering, etc.
>
> The very point is, the client would not render the thumbnails at all.
> The compositor would. Painting a copy of a window at another location
> should be fairly easy in theory. From your client perspective it would
> be a little like a special sub-surface whose content magically just
> appears on screen.
>
> >  However, then there's
> >
> > the question of whether it can be a standard protocol or not.
> >
> >
> > It is important that it is a standard, cross-compositor protocol. For
> > example, if I am using my app on "xfwm-wayland" and then I decide that I
> > want to switch to KWin, my app should continue to work.
>
> I would be very surprised if KWin developers would actually support
> that wish.
>
> FWIW, I do not believe at all, that the major DEs would implement
> support for adding third party DE components like what you want. They
> already have and develop their own stuff, and adding support for random
> third-party bits just makes for a huge maintenance addition.
>
> I could be wrong on that, but if I am, I will be surprised.
>

I can confirm that Enlightenment has no plans to implement anything like
this in the future.


>
> Your target audience would be the small DE or compositor projects who
> cannot build everything on their own.
>
> Even if you came up with a protocol design that also Wayland upstream
> saw as a good one (which is not exactly necessary, btw.), that still
> would not force anyone to implement it. There is no committee that
> decides what extensions everyone else must support. You have to sell
> your proposal to every DE project individually.
>
>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160512/f566eeb5/attachment.html>