Re: Protocol for window previews/thumbnails
On Tue, 14 Jun 2016 13:49:15 +0100 adlo wrote: > Any ideas about this? Not really, no. Someone has to be the first, solve his own problems, and then see if others can leverage the same solution. It is much harder trying to design something generic when you don't have any specifics. Thanks, pq > > On 7 Jun 2016, at 16:04, adlo wrote: > > > > There are many other protocols that may require handles to windows. > > It may make sense for them to all use the same handle protocol. Of > > course, all of these different protocols would require different > > levels and types of privileges. > > > > For example, a window switcher application would also need a > > protocol that can control windows in many ways, such as minimizing, > > maximizing, closing, moving, and focusing them, as well as getting > > the title of windows. However, the preview protocol, using the same > > handle type, would not need to access these functions. Is it > > possible to have a non-privileged interface using a privileged > > handle without any security issues? > > > > Also, Derek's reply mentions a "common module framework". How is > > this different from a Wayland protocol, and what are its advantages? > > > > Regards > > > > adlo > > > > > >> On 1 Jun 2016, at 09:00, Pekka Paalanen > >> wrote: > >> > >> On Tue, 31 May 2016 14:49:38 +0100 > >> adlo wrote: > >> > On 20 May 2016, at 08:50, Pekka Paalanen > wrote: > > You would design a new protocol extension private to Weston, > with which you deliver to your client the handles for top-level > windows as they come and go. > >>> > >>> This should probably be a separate protocol from the preview > >>> protocol. Is it possible to integrate the handle and preview > >>> protocol with another protocol, such as xdg-shell, so that the > >>> handles are delivered as xdg_surfaces and the preview protocol > >>> accepts xdg_surfaces as input? > >> > >> No. Not for what you would like to use it. That simply is not what > >> xdg_surface is for, and none of the xdg_surface API or any other > >> API using xdg_surface would apply. So it is totally inappropriate > >> to try to shoehorn xdg_surface in there. > >> > >> The handles would usually represent surfaces that have a > >> xdg_surface associated in the originating client, but it makes no > >> sense to try to call the handle a xdg_surface. The handles are > >> used completely differently than xdg_surfaces. > >> > >> There is also a practical issue: to create an xdg_surface with > >> xdg_shell, you first need a wl_surface. However, you cannot refer > >> to a wl_surface of another client. That is the whole reason you > >> need to create handles in the first place, to be able to refer to > >> surfaces that are not your own. > >> > >>> Is xdg-shell designed to be used by third-party clients for > >>> controlling windows in a similar way to libwnck? Does xdg-shell > >>> expose the inner workings of the compositor thus making it > >>> unsuitable? > >> > >> As Jonas said, no. > >> > >> > >> Thanks, > >> pq pgpFUuwkTZwox.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Any ideas about this? > On 7 Jun 2016, at 16:04, adlo wrote: > > There are many other protocols that may require handles to windows. It may > make sense for them to all use the same handle protocol. Of course, all of > these different protocols would require different levels and types of > privileges. > > For example, a window switcher application would also need a protocol that > can control windows in many ways, such as minimizing, maximizing, closing, > moving, and focusing them, as well as getting the title of windows. However, > the preview protocol, using the same handle type, would not need to access > these functions. Is it possible to have a non-privileged interface using a > privileged handle without any security issues? > > Also, Derek's reply mentions a "common module framework". How is this > different from a Wayland protocol, and what are its advantages? > > Regards > > adlo > > >> On 1 Jun 2016, at 09:00, Pekka Paalanen wrote: >> >> On Tue, 31 May 2016 14:49:38 +0100 >> adlo wrote: >> On 20 May 2016, at 08:50, Pekka Paalanen wrote: You would design a new protocol extension private to Weston, with which you deliver to your client the handles for top-level windows as they come and go. >>> >>> This should probably be a separate protocol from the preview >>> protocol. Is it possible to integrate the handle and preview protocol >>> with another protocol, such as xdg-shell, so that the handles are >>> delivered as xdg_surfaces and the preview protocol accepts >>> xdg_surfaces as input? >> >> No. Not for what you would like to use it. That simply is not what >> xdg_surface is for, and none of the xdg_surface API or any other API >> using xdg_surface would apply. So it is totally inappropriate to try to >> shoehorn xdg_surface in there. >> >> The handles would usually represent surfaces that have a xdg_surface >> associated in the originating client, but it makes no sense to try to >> call the handle a xdg_surface. The handles are used completely >> differently than xdg_surfaces. >> >> There is also a practical issue: to create an xdg_surface with >> xdg_shell, you first need a wl_surface. However, you cannot refer to a >> wl_surface of another client. That is the whole reason you need to >> create handles in the first place, to be able to refer to surfaces that >> are not your own. >> >>> Is xdg-shell designed to be used by third-party clients for >>> controlling windows in a similar way to libwnck? Does xdg-shell >>> expose the inner workings of the compositor thus making it unsuitable? >> >> As Jonas said, no. >> >> >> Thanks, >> pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
There are many other protocols that may require handles to windows. It may make sense for them to all use the same handle protocol. Of course, all of these different protocols would require different levels and types of privileges. For example, a window switcher application would also need a protocol that can control windows in many ways, such as minimizing, maximizing, closing, moving, and focusing them, as well as getting the title of windows. However, the preview protocol, using the same handle type, would not need to access these functions. Is it possible to have a non-privileged interface using a privileged handle without any security issues? Also, Derek's reply mentions a "common module framework". How is this different from a Wayland protocol, and what are its advantages? Regards adlo > On 1 Jun 2016, at 09:00, Pekka Paalanen wrote: > > On Tue, 31 May 2016 14:49:38 +0100 > adlo wrote: > >>> On 20 May 2016, at 08:50, Pekka Paalanen wrote: >>> >>> You would design a new protocol extension private to Weston, with which >>> you deliver to your client the handles for top-level windows as they >>> come and go. >> >> This should probably be a separate protocol from the preview >> protocol. Is it possible to integrate the handle and preview protocol >> with another protocol, such as xdg-shell, so that the handles are >> delivered as xdg_surfaces and the preview protocol accepts >> xdg_surfaces as input? > > No. Not for what you would like to use it. That simply is not what > xdg_surface is for, and none of the xdg_surface API or any other API > using xdg_surface would apply. So it is totally inappropriate to try to > shoehorn xdg_surface in there. > > The handles would usually represent surfaces that have a xdg_surface > associated in the originating client, but it makes no sense to try to > call the handle a xdg_surface. The handles are used completely > differently than xdg_surfaces. > > There is also a practical issue: to create an xdg_surface with > xdg_shell, you first need a wl_surface. However, you cannot refer to a > wl_surface of another client. That is the whole reason you need to > create handles in the first place, to be able to refer to surfaces that > are not your own. > >> Is xdg-shell designed to be used by third-party clients for >> controlling windows in a similar way to libwnck? Does xdg-shell >> expose the inner workings of the compositor thus making it unsuitable? > > As Jonas said, no. > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Tue, 31 May 2016 14:49:38 +0100 adlo wrote: > > On 20 May 2016, at 08:50, Pekka Paalanen wrote: > > > > You would design a new protocol extension private to Weston, with which > > you deliver to your client the handles for top-level windows as they > > come and go. > > > > This should probably be a separate protocol from the preview > protocol. Is it possible to integrate the handle and preview protocol > with another protocol, such as xdg-shell, so that the handles are > delivered as xdg_surfaces and the preview protocol accepts > xdg_surfaces as input? No. Not for what you would like to use it. That simply is not what xdg_surface is for, and none of the xdg_surface API or any other API using xdg_surface would apply. So it is totally inappropriate to try to shoehorn xdg_surface in there. The handles would usually represent surfaces that have a xdg_surface associated in the originating client, but it makes no sense to try to call the handle a xdg_surface. The handles are used completely differently than xdg_surfaces. There is also a practical issue: to create an xdg_surface with xdg_shell, you first need a wl_surface. However, you cannot refer to a wl_surface of another client. That is the whole reason you need to create handles in the first place, to be able to refer to surfaces that are not your own. > Is xdg-shell designed to be used by third-party clients for > controlling windows in a similar way to libwnck? Does xdg-shell > expose the inner workings of the compositor thus making it unsuitable? As Jonas said, no. Thanks, pq pgpL2MnbxzdWC.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Tue, May 31, 2016 at 02:49:38PM +0100, adlo wrote: > > > On 20 May 2016, at 08:50, Pekka Paalanen wrote: > > > > You would design a new protocol extension private to Weston, with which > > you deliver to your client the handles for top-level windows as they > > come and go. > > > > This should probably be a separate protocol from the preview protocol. Is it > possible to integrate the handle and preview protocol with another protocol, > such as xdg-shell, so that the handles are delivered as xdg_surfaces and the > preview protocol accepts xdg_surfaces as input? You won't be able to create an xdg_surface from not-xdg_shell because of the single-factory principle, but with v6 it would theoretically be possible to create an xdg_surface and assign it a role not defined in xdg_shell. > > Is xdg-shell designed to be used by third-party clients for controlling > windows in a similar way to libwnck? Does xdg-shell expose the inner workings > of the compositor thus making it unsuitable? No. xdg_shell will not work as a desktop environment component protocol. It's targeted at toolkits and clients that act as regular clients. Jonas > > Regards > > adlo > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 20 May 2016, at 08:50, Pekka Paalanen wrote: > > You would design a new protocol extension private to Weston, with which > you deliver to your client the handles for top-level windows as they > come and go. > This should probably be a separate protocol from the preview protocol. Is it possible to integrate the handle and preview protocol with another protocol, such as xdg-shell, so that the handles are delivered as xdg_surfaces and the preview protocol accepts xdg_surfaces as input? Is xdg-shell designed to be used by third-party clients for controlling windows in a similar way to libwnck? Does xdg-shell expose the inner workings of the compositor thus making it unsuitable? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Thu, 26 May 2016 13:52:58 +0100 adlo wrote: > > On 24 May 2016, at 16:06, Pekka Paalanen wrote: > > > > The "private to weston" also means it should be a privileged interface: > > arbitrary clients must not be able to use it, as it's none of their > > concern and could be a security concern. > > > > What about Wayland Security Modules (libwsm)? In what ways does this > not solve the security issues of privileged interfaces? I am only saying you have to pay attention to security there too. What you will use to implement it is up to each compositor on its own. Thanks, pq pgpMWUNzvYTnt.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 11 May 2016, at 09:07, Pekka Paalanen wrote: > > If some sort of protocol would be needed, then you have to figure out > how to not make it a gaping security breach > What about Wayland Security Modules (libwsm)? In what ways does this fail to address the security issues with privileged interfaces? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Hi Benoit, On 28 May 2016 at 12:45, Benoit Gschwind wrote: > You should keep an eye on libweston :) Yes indeed, I do have great hopes in libweston :) Cheers, Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Hello Olivier, You should keep an eye on libweston :) Best regards Le 20/05/2016 10:33, Olivier Fourdan a écrit : > Hi, > > On 12 May 2016 at 00:35, ade low wrote: >> [...] >> 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. > > As a side note, there is no such thing as "xfwm-wayland" and there > will probably never will be, at least not from me. > > I reckon writing a Wayland compositor is simply too much work for a > single developer, it's an entirely different world from an X11 window > manager, many of the functionalities that were previously handled for > us by the X server now fall under the role of the compositor manager > in Wayland (input devices, output, etc.). > > FWIW, if xfce were to support Wayland some day, we'd probably built it > on top of an existing compositor manager (mutter is probably the best > bet for a gtk+ based environment) and just like with GNOME shell, > window previews/thumbnails would be handled in the compositor/shell. > > Cheers, > Olivier > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 24 May 2016, at 16:06, Pekka Paalanen wrote: > > The "private to weston" also means it should be a privileged interface: > arbitrary clients must not be able to use it, as it's none of their > concern and could be a security concern. > What about Wayland Security Modules (libwsm)? In what ways does this not solve the security issues of privileged interfaces? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Tue, 24 May 2016 14:53:25 +0100 adlo wrote: > > On 20 May 2016, at 08:50, Pekka Paalanen wrote: > > > > You would design a new protocol extension private to Weston, with which > > you deliver to your client the handles for top-level windows as they > > come and go. Then with those handles you could design a protocol for > > laying out a scaled version of the surface referred to by a handle on > > top of a wl_surface of your own. > > Can a Weston protocol extension be easily converted to a Wayland protocol > extension? Technically there is no difference. You cannot expect anyone else to implement it, though, just like we have explained and people have already said they won't implement anything like it. The "private to weston" also means it should be a privileged interface: arbitrary clients must not be able to use it, as it's none of their concern and could be a security concern. > > > > You cannot get "the window's surface". You need to invent a new > > type of handle (a protocol object interface) for referring to > > windows, and communicate any metadata you may need with it. > > What is Weston's internal representation of a window's surface? What > parts of the code are most relevant to these kinds of things? struct weston_view is the thing that goes on screen (the scenegraph), and gets its content from struct weston_surface. You also need to integrate with the desktop-shell plugin to identify proper windows apart from everything else that is a weston_surface. Thanks, pq pgp6y9FwumHiz.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 20 May 2016, at 08:50, Pekka Paalanen wrote: > > You would design a new protocol extension private to Weston, with which > you deliver to your client the handles for top-level windows as they > come and go. Then with those handles you could design a protocol for > laying out a scaled version of the surface referred to by a handle on > top of a wl_surface of your own. Can a Weston protocol extension be easily converted to a Wayland protocol extension? > > You cannot get "the window's surface". You need to invent a new type of > handle (a protocol object interface) for referring to windows, and > communicate any metadata you may need with it. What is Weston's internal representation of a window's surface? What parts of the code are most relevant to these kinds of things? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 20 May 2016, at 09:33, Olivier Fourdan wrote: > > FWIW, if xfce were to support Wayland some day, we'd probably built it > on top of an existing compositor manager (mutter is probably the best > bet for a gtk+ based environment) and just like with GNOME shell, > window previews/thumbnails would be handled in the compositor/shell. Does mutter support pixman 2D software rendering? I believe that xfwm4 supports this through XRender. Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Hi, On 12 May 2016 at 00:35, ade low wrote: > [...] > 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. As a side note, there is no such thing as "xfwm-wayland" and there will probably never will be, at least not from me. I reckon writing a Wayland compositor is simply too much work for a single developer, it's an entirely different world from an X11 window manager, many of the functionalities that were previously handled for us by the X server now fall under the role of the compositor manager in Wayland (input devices, output, etc.). FWIW, if xfce were to support Wayland some day, we'd probably built it on top of an existing compositor manager (mutter is probably the best bet for a gtk+ based environment) and just like with GNOME shell, window previews/thumbnails would be handled in the compositor/shell. Cheers, Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Thu, 19 May 2016 18:10:19 +0100 adlo wrote: > > On 12 May 2016, at 08:57, Pekka Paalanen wrote: > > > > On Wed, 11 May 2016 23:35:01 +0100 > > ade low wrote: > >> 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 there is no protocol, what could be an alternative way for > third-party window switchers to be implemented on Wayland compositors? In general, so that it would work anywhere? None; see Mike's reply. For specific compositors you might be able to implement plugins, or maintain a fork of the compositor project. > >> 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. > >> > > 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. > > If I wanted to try writing something like this as a Weston extension > for testing purposes, how could I get the window's surface? You would design a new protocol extension private to Weston, with which you deliver to your client the handles for top-level windows as they come and go. Then with those handles you could design a protocol for laying out a scaled version of the surface referred to by a handle on top of a wl_surface of your own. You cannot get "the window's surface". You need to invent a new type of handle (a protocol object interface) for referring to windows, and communicate any metadata you may need with it. Thanks, pq pgpoMreDpxLkR.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
> On 12 May 2016, at 08:57, Pekka Paalanen wrote: > > On Wed, 11 May 2016 23:35:01 +0100 > ade low wrote: >> 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 there is no protocol, what could be an alternative way for third-party window switchers to be implemented on Wayland compositors? > >> 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. >> > 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. If I wanted to try writing something like this as a Weston extension for testing purposes, how could I get the window's surface? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Thu, May 12, 2016 at 3:57 AM Pekka Paalanen wrote: > On Wed, 11 May 2016 23:35:01 +0100 > ade low wrote: > > > Thank you for the feedback, that was very helpful. > > > > On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Wed, 11 May 2016 23:35:01 +0100 ade low wrote: > Thank you for the feedback, that was very helpful. > > On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen 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 pgp3KMxZlmix7.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Thanks for your feedback too. On Wed, May 11, 2016 at 2:51 PM, Derek Foreman wrote: > > > But I'm of the opinion that this doesn't need to be a "wayland" problem > at all - but I'm not saying there can't be a standard way to do this. > > It just doesn't need to be solved by adding wayland protocol. A common > module framework for compositors that find this functionality useful > would probably perform better and have less complexity. > Do you mean something like a shared library that compositors can link against? Does this mean that compositors would not have to have their own implementation of this functionality as it would be provided by this library, or have I understood this incorrectly? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
Thank you for the feedback, that was very helpful. On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen 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 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. 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. 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. Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On 11/05/16 03:07 AM, Pekka Paalanen wrote: > On Tue, 10 May 2016 21:30:53 +0100 > ade low wrote: > >> I think that it would be a good idea to have a standard, cross-compositor >> protocol for getting previews/thumbnails of windows, similar to XComposite. > > Hi, > > I strongly disagree. A huge part of Wayland's reason to exist is that > things like XComposite protocol are not necessary. > >> This protocol should be as fast as possible and use as little system >> resources as possible. It should probably provide a handle to the native >> window surface. >> >> It will also be necessary to receive damage events on these surfaces. I >> don't know if this should be included in this protocol or if this should be >> a separate protocol? >> >> Does anyone have any ideas on the best way to design such a protocol? > > "Don't do it" is the only answer based on just this information you > gave. Right - and I'll be quick to stand behind Pekka on this one. I think this is generally considered something that should be done inside the compositor - but I also think the compositor itself could expose some manner of API/modular interface/whatever to allow external code to do this. That is, wayland protocol is not required for a compositor to allow this to happen. And this is a key point people miss when "wayland refuses to support external task switchers" or whatever shows up as a thread on reddit. :) Wayland is not preventing desktops from allowing third party application switchers/pagers/previewers. > 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. > > If some sort of protocol would be needed, then you have to figure out > how to not make it a gaping security breach, and how to not interfere > with other clients too badly or cause too much work for the compositor. > You would also have to figure out how and to what level to synchronize > things between at least four different actors: your client, the > compositor, a normal client, and the compositor again. > > 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. However, then there's > the question of whether it can be a standard protocol or not. FWIW, if I had to address this problem, that is probably the route I'd take. There are a lot of different buffer objects and formats to deal with, and the compositor already knows how. Also, keeping the actual contents out of the hands of other applications (not just for security, but to keep them from leaking giant chunks of shmem or screwing up timing) seems like a win. But I'm of the opinion that this doesn't need to be a "wayland" problem at all - but I'm not saying there can't be a standard way to do this. It just doesn't need to be solved by adding wayland protocol. A common module framework for compositors that find this functionality useful would probably perform better and have less complexity. Thanks, Derek > > > Thanks, > pq > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Protocol for window previews/thumbnails
On Tue, 10 May 2016 21:30:53 +0100 ade low wrote: > I think that it would be a good idea to have a standard, cross-compositor > protocol for getting previews/thumbnails of windows, similar to XComposite. Hi, I strongly disagree. A huge part of Wayland's reason to exist is that things like XComposite protocol are not necessary. > This protocol should be as fast as possible and use as little system > resources as possible. It should probably provide a handle to the native > window surface. > > It will also be necessary to receive damage events on these surfaces. I > don't know if this should be included in this protocol or if this should be > a separate protocol? > > Does anyone have any ideas on the best way to design such a protocol? "Don't do it" is the only answer based on just this information you gave. 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. If some sort of protocol would be needed, then you have to figure out how to not make it a gaping security breach, and how to not interfere with other clients too badly or cause too much work for the compositor. You would also have to figure out how and to what level to synchronize things between at least four different actors: your client, the compositor, a normal client, and the compositor again. 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. However, then there's the question of whether it can be a standard protocol or not. Thanks, pq pgpzUgGUBswno.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Protocol for window previews/thumbnails
I think that it would be a good idea to have a standard, cross-compositor protocol for getting previews/thumbnails of windows, similar to XComposite. This protocol should be as fast as possible and use as little system resources as possible. It should probably provide a handle to the native window surface. It will also be necessary to receive damage events on these surfaces. I don't know if this should be included in this protocol or if this should be a separate protocol? Does anyone have any ideas on the best way to design such a protocol? Thank you Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel