Window thumbnail discussion

[Martin Graesslin]

On Thursday, January 21, 2016 12:06:48 PM CET Martin Gräßlin wrote:
> I plan to write something down in the wiki next week, which should be a
> better starting point for discussions then.

Created a wiki page: https://community.kde.org/KWin/Window_Metadata

Please feel free to extend/fix as needed :-)

Cheers
Martin

The content I added is:

=Window Metadata=
==Rational==

Window Thumbnails as scaled down window content are hardly useable. Windows of 
same application are hardly distinguishable from each other which eliminates 
all advantages from thumbnails in first place.

In addition on Wayland it is difficult to get access to live-updating window 
thumbnails in the desktop shell. While the compositor has access to the window 
content, other applications do not. This would require a custom protocol to 
pass the window content from the compositor to the desktop shell. A protocol 
would be required which would be fairly close to being an own Wayland server.

This document describes how to put the application more in control of the 
window thumbnail which will be rendered.

== General Architecture ==

The protocol will be implemented using DBus to be windowing system agnostic. 
The window manager registers a DBus service "org.kde.kwin.windowmetadata1" and 
the object path "/org/kde/kwin/WindowMetadata1". On this interface there is a 
call "register" which allows an application to call it and to indicate that it 
supports the protocol.

The window manager is able to map windows to the DBus peer through the PID. On 
both X11 and Wayland the window manager has access to the PID. In case of 
Wayland this is only possible for the window manager, thus the DBus service 
must be bound on the window manager.

When a thumbnail is required the window manager informs the application for 
which window and in which size a thumbnail is needed. In addition it passes a 
filedescriptor of a pipe to the application. The application renders the 
thumbnail and writes the rendering result into the pipe and closes the pipe 
once the rendering is
finished. The application can render a thumbnail of different size if this of 
more use. To support that a small binary protocol on the pipe is required. It 
needs to describe:
 * size (width/height)
 * stride
 * image format
 * byte count
 * binary data

Obviously the server side needs to sanity check the values.

The protocol is not meant to have life-updating previews. There is a DBus call 
for the application to indicate that it has new data available, but it's the 
responsibility of the server to initiate the process. By that the server can 
control the updates to a sensible amount.

== Passing thumbnail to Desktop Shell ==

Internal implementation detail, to be defined.

== Window Actions ==

An additional idea is to allow the application to specify additional actions 
through the DBus interface. E.g. a "reload" action in a browser. This is 
intended to be implemented in a future release.

== Implementation ==

The implementation will be provided through a tier1 framework. It will be 
windowing system agnostic and only depends on DBus. For the application it 
will be as simple as just rendering to a QImage (through QPainter) or using a 
special QtQuick import.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160125/df2aa42f/attachment-0001.sig>