Protocol for window previews/thumbnails

[adlo]

Any ideas about this?

> On 7 Jun 2016, at 16:04, adlo <adloconwy at gmail.com> 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 <ppaalanen at gmail.com> wrote:
>> 
>> On Tue, 31 May 2016 14:49:38 +0100
>> adlo <adloconwy at gmail.com> wrote:
>> 
>>>> On 20 May 2016, at 08:50, Pekka Paalanen <ppaalanen at gmail.com> 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