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