There was a nice feature called KDE Snap Assistant that broke because Plasma 6 introduced fundamental architectural changes without caring to create a compatibility layer that shattered the scripting ecosystem. The dev simply gave up on KDE after that, as you can see here: Add support for Plasma 6 · Issue #47 · emvaized/kde-snap-assist · GitHub
The Problem is that KWin’s QML modules were inconsistently ported: some components moved to v3.0, others stayed at 2.0, and some were completely removed. The workspace object is no longer automatically injected into all QML/JS contexts. It’s only available in specific execution environments.
Considering hell, I decided to port KDE Snap Assistant to Plasma 6 so I can have the only Micro$oft Windows feature (Windows Snap Assistant) that keeps me on the hook that is easing my workflow managing windows with visual aids created once you snap a windows on the side of your screen, WITHOUT THE NEED OF KEYBOARD USAGE. There is no feature like that on KDE Plasma 6 yet, period. There’s on Gnome though (Tiling Assistant) AND on Samsung Dex (Android) though.
Going through this painfully, I’m rn facing a classic bootstrapping problem where each solution requires the other to work first:
Problem A: JavaScript Can’t Access QML
// main.js - CAN detect snaps, but...
function showInterface() {
// ❌ Qt.createComponent() - NOT AVAILABLE in KWin scripting context
// ❌ Can't instantiate QML from JavaScript
// ❌ Can't show visual interface with thumbnails
}
Problem B: QML Can’t Access KWin APIs
// main.qml - CAN show interface, but...
Item {
Component.onCompleted: {
// ❌ workspace is not defined
// ❌ Can't detect window events
// ❌ Can't access window objects
}
}
Problem C: Communication Channel Broken
// The Bridge is BROKEN
workspace.someProperty = data // ❌ Not be accessible from QML AFAIK
globalThis.sharedData = data // ❌ globalThis doesn't exist in KWin
The Vicious Cycle:
- JavaScript has KWin API access but can’t create UI
- QML can create UI but can’t access KWin APIs
- Communication between them is unreliable or non-existent
I tried my best to get creative and thought to custom TabBox component but I started to notice that I had to beginning to change Kwin itself to make it work once * TabBox infrastructure exists but can’t be programmatically triggered. TabBox infrastructure exists but and can’t be programmatically triggered afaik, being defined only to answer to keyboard shortcuts. Besides that when TabBox activates, it hijacks the entire input system. This makes it impossible to trigger from within a script’s event handler.
I don’t know how the heck did they manage to fragments these capabilities across incompatible contexts. It’s truly a technological marvel.
Am I missing something? How can I solve that? Are they planning on launching a unified scripting API, programmatic UI activation or cross-context communication or if this is a must for me I should just give up on KDE to get onboard of Wayland? I can’t see a solution that doesnt involvers having to change Kwin itself to make it work. HELP 
Or can I ask a Snap Assistant for KDE as a native feature for Christmas?
