It looks like KWin does not exposes stacking order to its scripting system anyhow. The only way to access list of managed clients by KWin is to call allClientList() (or m_allClients) from workspace.h, which is not sorted at all. And clients itself do not have any information about current stacking order. The other way to access stacking order would be accessing root window property '_NET_CLIENT_LIST_STACKING(WINDOW)'. But again — there is no way from KWin scripting to access root window or its properties. As for use cases. My general use case would be writing some advanced focus switching plugins, which are not really belongs to KWin core. Indeed, X11 allows to write some plugins without a invovlment of windows manager. But that way a lot of information is lost, e.g. list of activities to which some window belongs to. So I am requesting a feature to somehow provide stacking order to KWin scripting, for example just giving direct access to workspace.stacking_order list from workspace wrapper.
> m_allClients) from workspace.h, which is not sorted at all We don't maintain stacking order in m_allClients. There are currently several stacking orders: * Unconstrained (unconstrained_stacking_order): the first client in the list is the bottom-most client, and the last client in the list is the top-most client. Only managed clients are in tjhe list; * Constrained (stacking_order): it's the same as the unconstrained stacking order. The only difference between two is that in this list "below-above" constraints are evaluated; * Render (x_stacking): This is concatenation of the constrained stacking order and a list of unmanaged/internal clients. Keep in mind that we use X's stacking order only for unmanaged clients. I guess we could add something like this to the scripting API // We use QtScriptEngine so no ECMAScript 6 features. var clients = workspace.stackingOrder(); workspace.stackingOrderChanged.connect(function () { console.log('Yo!'); }); though I'm not sure about declarative script API, perhaps we need to expose stackingOrder property. Given that Deleted is an implementation detail of kwin, we must filter out such toplevels.
> I guess we could add something like this to the scripting API Great! I have fears that there are some fundamental problems that prevents exposing these structures to the scripting API. > though I'm not sure about declarative script API, perhaps we need to expose stackingOrder property. I guess it will be the same as already existing cleints property. As long as this is not a read-write property, it should be relativly simple to do. > Given that Deleted is an implementation detail of kwin, we must filter out such toplevels. Agreed. Anyway, I see no reason why scripting API should have access to this 'Deleted' lists. Any ETA on implementing this? The task looks doable for me from my unprepared eye, so given the information you just shared, I guess I can prepare a patch after the weekends.
(In reply to Mikhail Skorzhinskii from comment #2) > Any ETA on implementing this? That's up to you. > The task looks doable for me from my unprepared eye, so given the > information you just shared, I guess I can prepare a patch after the > weekends. Great! If that's your first contribution, then here are some useful resources to learn how to setup a dev environment and how to submit the patch * https://community.kde.org/Infrastructure/Phabricator * https://community.kde.org/Get_Involved/development
Please be aware that stacking order would be read only. To manipulate you would have to use the existing API calls.
I don't know if this has been recently implemented or always been there and just never documented, but it works for me: > client.stackingOrder