.. or it could be a library rather than a service?
Honestly, a library (khm khm solid) would be imo the right target. First, we
can make it as a separate one, and then merge into solid when we are satisfied
by it, and when kf5/solid is deemed stable.
screen resolution is already handled by
On Sunday, June 2, 2013 10:57:44 Ivan ÄukiÄ wrote:
screen resolution is already handled by other means. the only use case i
can actually think for any of the things listed is the keyboard: if there
is a hardware keyboard, don't show the on-screen software keyboard.
How so? If we have a
Hi all,
For the shell switching / capabilities-based component loading, we'll need to
have the system to get the capabilities of UI devices (obviously :) ).
The service (guessing org.kde.platformstatus will fit this purpose) will need
to be able to:
- get the keyboard, attached/detached
On Saturday, June 1, 2013 19:27:16 Ivan ÄukiÄ wrote:
Hi all,
For the shell switching / capabilities-based component loading, we'll need
to have the system to get the capabilities of UI devices (obviously :) ).
The service (guessing org.kde.platformstatus will fit this purpose) will
need
