depends from D9521
listens to switch events and updates the tablet mode status
which is exposed to dbus in the org.kde.KWin.TabletModeManager
interface
graesslin |
Plasma | |
KWin |
depends from D9521
listens to switch events and updates the tablet mode status
which is exposed to dbus in the org.kde.KWin.TabletModeManager
interface
as hardware support is limited, testing of clients
so far is done by the setter in the dbus property,
which should be removed from the final version.
It has been tested to successfully work on a Thinkpad.
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
DBus code is all good.
It would be nice if you can run qdbuscpp2xml on the TabletModeManager and install that .xml file in /usr/share/dbus-1/services it will allow other programs to generate the client side interface programatically.
one thing i'm wondering, is how to manage dependencies, as ideally we want most of our apps to make use of this, but can't ask for sure to depend from kwin..., which finding the xml would make it an hard dependency (maybe one could still work around by connecting blindly to that by hand)
maybe a new framework which provides the XML and a small client side wrapper? Could probably be tier1.
tabletmodemanager.cpp | ||
---|---|---|
76 | please put into initializer. Also the spy leaks. | |
87–88 | = default | |
107 | is that needed? | |
workspace.cpp | ||
183 ↗ | (On Diff #25022) | I would create it in main_wayland.cpp in ApplicationWayland::performStartup just before creating the virtualkeyboard. Reason: this is currently Wayland only code and we might not want to expose the dbus service on X11. Reason for just before creating virt keyboard: I want to use that to automatically enable the virtual keyboard if we are in tablet mode. |
do you think it should be in a new standalone framework or is there anything already existing which could have it?
maybe one could still work around by connecting blindly to that by hand
There's nothing inherently wrong with doing that. Assuming the DBus API is stable is as valid and as easy as assuming the a library is valid and stable.
If you're going to expose it in Kirigami, then I wouldn't bother doing anything else.
yeah, we have to promiseapi stability for all kf5 like on that kwin interface, that's for sure.
ok, so kirigami already has a public library as well, so if done here, this could be used directly in qml (there is already a singleton which exposes an ismobile variable, which not would change dinamically at runtime), but also from any c++ program, which would be nice.