KWin/Browser Integration

Exposed Tabs

The Exposed Tab Extension allows tabbed user interfaces to expose their tabs to the desktop shell. The desktop shell may use this information to allow switching to a tab directly through a tasks overview (such as a task bar) and to integrate them in the compositor to also have thumbnails for tabs.

Announcing Support

The window manager/compositor adds _KDE_NET_WM_EXPOSED_TABS to _NET_WM_SUPPORTED if it supports the exposed tab functionality.

New Properties

Two new properties on the client are required for the functionality:

* _KDE_NET_WM_EXPOSED_TABS
* _KDE_NET_WM_CURRENT_EXPOSED_TAB

_KDE_NET_WM_EXPOSED_TABS

_KDE_NET_WM_EXPOSED_TABS is used by the client to inform interested parties about which tabs are exposed and how they look like. The structure of the property consists first of an unsigned long indicating the number of exposed tabs, followed by a repeated structure of:

* unsigned long: unique id for the tab to be specified by the client
* unsigned long: native pixmap handle for the icon
* unsigned long: native pixmap handle for the thumbnail (unscaled)
* unsigned long: length of the title of the tab
* char[]: title of the tab - has to be equal to the length

It is the responsibility of the client to keep the pixmaps for icon and thumbnail around as long as the tab is exposed. The pixmap for the thumbnail should be unscaled. The compositor is able to scale the pixmap in a more efficient way. The compositor might want to display the thumbnail in a readable way, therefore it should not be scaled by the client.

The client has to update this property whenever the number of exposed tabs changes, that is if one is added or removed. The unique ids should not change for an exposed tab as long as the tab is exposed. This information might be used by the compositor for caching. The pixmap handle should only be updated if the size of the pixmap changes. Rendering updates should happen on the same pixmap. The compositor is able to track changes through the damage extension.

_KDE_NET_WM_CURRENT_EXPOSED_TAB

_KDE_NET_WM_CURRENT_EXPOSED_TAB contains the unique id of the current selected exposed tab. If none of the exposed tabs is selected, the property should be set to an empty value. The client has to keep the information up to date. The compositor uses this information for e.g. highlighting the currently selected tab in overviews.

The compositor is allowed to change this property. In that case the client has to switch to the exposed tab or set it back to the correct tab. By allowing the compositor to change the exposed tab the user can change tabs in UI provided by the compositor (e.g. thumbnail overviews).

Implementation in KWin

Adding support to the compositor is rather trivial. After all the exposed tabs are basically just pixmaps and KWin can use the damage extension and texture from pixmap to track changes and render the thumbnails.

In the core some changes are required. A new class "ClientAddition" (not using anything related to tab to not confuse with window tabbing) inheriting Toplevel needs to be added. The Client needs a new property to hold a list of ClientAdditions. The ClientAdditions need to be kept in sync with the property exposed by the client.

As ClientAddition is inheriting Toplevel it can be mapped to an EffectWindow. In case the EffectWindow represents a Client it needs to provide a method to retrieve the EffectWindows representing ClientAdditions. Furthermore a method to get the currently selected ClientAddition and a method to set the ClientAddition are required.

In the effects layer changes have to be added as requirements arise. It might make sense to include the client additions in Present Windows and maybe adding a new mode for just showing the additions (this could be triggered by the client application). Another effect which might be changed is tasbar thumbnail. Here the question is whether to let Plasma influence it or KWin decide. This mostly depends on whether the Tooltip functionality is completely moved to Plasma or not.

In core the TabBox might be extended to support ClientAdditions. An idea is to change the TabBox's model to a TreeModel and include the additions below the normal client in maybe a collapsed state.