Next Gen CI: framework dependencies for KWin

Martin Flöser mgraesslin at kde.org
Sat May 6 17:55:14 BST 2017


Am 2017-05-06 11:37, schrieb Ben Cooksley:
> This is the second point that requires your attention. If your
> development process is dependent on using the latest development
> version of something which is located in another product, then we will
> need to add that to your Product. If this affects you, please start a
> new thread (CC'ing sysadmin and kde-core-devel along with your
> Product's main list) stating which specific repositories you need and
> providing one to two lines of explaination for each.

My requests for KWin:
  * KWindowSystem
  * KWayland
  * (optionally KGlobalAccel)
  * (optionally Plasma)

Reasoning:
KWindowSystem implements the X11 side of the Window Manager. This is 
mostly the NETWM classes. Normally a change in KWindowSystem is always 
triggered by a change in KWin.
Example from changes I implemented:
b7bd5f9a09cb3874532269838b53f03c800d8a44 in KWin and 
e333a13fc52c28aac3c0d28cd5b85e16428fcff7 in KWindowSystem

KWayland implements the server side of a Wayland compositor. Changes in 
KWayland are mostly triggered by the needs of KWin.
Example from changes I implemented:
1193b0da771a5d1042bf2aed0a2727f89ddf488e in KWin and 
6c89a61d2d17e1703b961566133cc5f46516b5a1 in KWayland

On Wayland KWin provides the runtime part of KGlobalAccel and therefore 
needs to interact with the library. As in the other cases changes are 
normally triggered from KWin, but over the last years changes were very 
seldom. Thus I don't think we absolutely need it. Given that it's not 
tier 1 I wouldn't be sad if I get a no here.

Similar for Plasma: it's a library KWin (indirectly) uses and sometimes 
changes are needed. But it's very seldom that a change is triggered by 
KWin.

Cheers
Martin




More information about the kde-core-devel mailing list