Re: Protocol for window previews/thumbnails

[Pekka Paalanen]

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

[adlo]

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

[adlo]

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

[Pekka Paalanen]

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

[Jonas Ådahl]

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

[adlo]

> 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

[Pekka Paalanen]

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

[adlo]

> 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

[Benoit Gschwind]

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

[adlo]

> 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

[Pekka Paalanen]

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

[adlo]

> 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

[Olivier Fourdan]

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

[Pekka Paalanen]

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

[adlo]

> 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

[Mike Blumenkrantz]

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

[Pekka Paalanen]

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

[ade low]

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

[ade low]

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

[Derek Foreman]

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

[Pekka Paalanen]

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