> On Jan. 5, 2015, 2:12 p.m., Thomas Lübking wrote: > > src/qmlcontrols/kwindowsystemplugin/kwindowsystemproxy.h, line 44 > > <https://git.reviewboard.kde.org/r/121856/diff/1/?file=338402#file338402line44> > > > > General question: > > How's the QML API doc created? > > Can one inject a warning here to not abuse this -maybe very tempting- > > call? > > Martin Gräßlin wrote: > best would be if we could keep the documentation in sync with > KWindowSystem.
QML API doc is created in exactly the same way as C++. As far as doxygen is concenred it is just any other class. In some classes like http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classPlasma_1_1SvgItem.html I added /// @cond INTERNAL_DOCS /// @endcond round anything that wasn't exposed to the metaobject system to make things neater. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121856/#review73164 ----------------------------------------------------------- On Jan. 5, 2015, 10:49 a.m., 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 a.m.) > > > 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 > >
_______________________________________________ Plasma-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/plasma-devel
