Protocol for window previews/thumbnails

[Pekka Paalanen]

On Tue, 14 Jun 2016 13:49:15 +0100
adlo <adloconwy at gmail.com> 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 <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  

-------------- 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/20160614/cf7bf4b0/attachment.sig>