Protocol for window previews/thumbnails

[Pekka Paalanen]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160512/b10daa0b/attachment.sig>