Review Request 121856: KWindowSystem import for KDeclarative

[Kai Uwe Broulik]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121856/#review73248
-----------------------------------------------------------


Thinking again about it I think methods such as "activeWindow" and "icon" definitely should be exposed in this import. This would be super handy for the window controls widget (you know, that netbook thing in your panel that shows the window title and offers close/maximize buttons). It would still need a plugin for invoking present windows and closing the window but the rest could be done without code duplication:

QWindow *KWindowSystemProxy::activeWindow() {
    return QWindow::fromWinId(KWindowSystem::activeWindow());
}
If I understood it correctly, Qt will generate a QWindow representation of that window (with title and everything set). Since that QWindow instance won't have a parent (I guess) it will be adpoted by the QML engine and thrown away when it goes out of scope (eg. you call var activewin = kwindowsystem.activeWindow(); console.log(activewin.title); and when that function ends it get collected by the GC)

So that shouldn't be too bad of an approach, no? Not sure about QList<QWindow *> though

- Kai Uwe Broulik


On Jan. 5, 2015, 10:49 vorm., Kai Uwe Broulik wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121856/
> -----------------------------------------------------------
> 
> (Updated Jan. 5, 2015, 10:49 vorm.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> -------
> 
> This is a thin proxy around KWindowSystem exposing most of its methods to qml via KWindowSystem item in an org.kde.kwindowsystem import.
> 
> It uses QWindow instead of WId parameters so you can just pass a qml Item, such as a Plasma Dialog as parameter for ease of use (and so you cannot mess with others windows without effort, also I don't know what "WId" would translate to anyway). It omits all those methods that return WId/QWindow as I don't know how expensive QWindow::fromWinId is or who takes ownership of it. We need to decide which methods make sense in this import.
> 
> Methods that have signals and don't take parameters are turned into full-fledged properties (like currentDesktop, numberOfDesktops, etc) and the rest stays Q_INVOKABLE.
> 
> 
> Diffs
> -----
> 
>   src/qmlcontrols/kwindowsystemplugin/qmldir PRE-CREATION 
>   src/qmlcontrols/kwindowsystemplugin/kwindowsystemproxy.cpp PRE-CREATION 
>   src/qmlcontrols/CMakeLists.txt 39c39a5 
>   src/qmlcontrols/kwindowsystemplugin/CMakeLists.txt PRE-CREATION 
>   src/qmlcontrols/kwindowsystemplugin/kwindowsystemplugin.h PRE-CREATION 
>   src/qmlcontrols/kwindowsystemplugin/kwindowsystemplugin.cpp PRE-CREATION 
>   src/qmlcontrols/kwindowsystemplugin/kwindowsystemproxy.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/121856/diff/
> 
> 
> Testing
> -------
> 
> The properties work and change accordingly (compositing active signal doesn't seem to be emitted by KWindowSystem in the first place, at least Ctrl+Shift+F12 doesn't make it change), the forceActivateWindow method works for Review 121807
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150106/a74b894c/attachment-0001.html>