<div dir="ltr"> <div class="gmail_quote"><div dir="ltr">On Thu, May 12, 2016 at 3:57 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 11 May 2016 23:35:01 +0100 ade low <<a href="mailto:adloconwy@gmail.com" target="_blank">adloconwy@gmail.com</a>> wrote: > Thank you for the feedback, that was very helpful. > > On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> 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: > <a href="https://github.com/adlocode/xfce4-lightdash-plugin" rel="noreferrer" target="_blank">https://github.com/adlocode/xfce4-lightdash-plugin</a> 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. </blockquote><div> </div><div>I can confirm that Enlightenment has no plans to implement anything like this in the future.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote></div></div>