Evolving Appdash

[Eike Hein]

I'd like to propose moving kdeplasma-addon's Appdash UI out of
kdeplasma-addons into plasma-desktop, fleshing it out a little
more and making it available in the following ways:

a) Global default keyboard shortcut
b) Desktop Toolbox entry
c) Available as hot corner action
d) Available as a now-optional panel widget

Fleshing out mainly refers to the addition of basic system
control knobs like networking toggles and display brightness.

Concretely, this would address user wishes to be able to access
Appdash without requiring the presence of a panel widget.

More broadly, the enhanced Appdash would satisfy the following
user scenarios without the need to have two panel widgets or
pick just one UI:

* $user is using a touchscreen laptop or 2-in-1 hybrid in
  tablet mode. They're using traditional desktop UI elements
  most of the time (e.g. when getting work done inside classic
  apps), but some of the time enjoy leaning back and using a
  more generously spaced, distraction-free UI with bigger
  touch targets. (Often e.g. as an onboarding experience to
  a touch-driven UI like PMC/Kodi or a tablet-friendly game.)

* $user is of the traditional mouse and keyboard variety and
  enjoys using a small windowed launcher for activities like
  drilling down to a specific menu category and app, but
  prefers using a fullscreen UI for search and exploration-
  like activity.

These user scenarios have been encountered on the issue tracker
and in user venues before in various forms. They exist right
now, but require some compromises from these users like adding
a panel applet that may be unused. Competitive pressure
(several products competing with Plasma Desktop now ship default
UI addressing these needs) adds to it.

During the IRC meeting there was some concern about diluting the
overall UI by having "more than one way to do it", however in the
above user scenarios this appears desired, because:

* "Doing it" is a very subtle thing. "Start any application" might
  appear to be "it", but in reality the difference between "start
  an application I know about" and "look around the apps I have
  installed to see whether I want to start one" can matter, for
  example, and different UIs support different frame of mind to
  varying degrees.

* Plasma Desktop is positioned as a UI product for multi form
  factor devices which change form factor at runtime due to both
  physical reconfiguration of the device (de- and reattaching
  the screen/keyboard) and user frame of mind (whatever compells
  a user to poke the screen instead of using the trackpad at any
  moment). We've long had goals to support this sort of thing
  well (shell package swapping, form factor awareness in core
  frameworks, etc., are a reflection of this) and this proposal
  is meant as a prong of the same fork: Iterate on the UI we
  make available to hybrid devices to get closer to our goals.

The proposal aims to achieve this by (a) evolving and making
suitable and popular UI we have available in the core desktop
package and (b) keeping it unobtrusive by default (if you don't
use it, you can ignore it).

In terms of implementation, abstracting things so the actual
Appdash implementation implements some sort of generic interface
called by shell code seems fine. Note that the Appdash code is
effectively already in p-d (kdeplasma-addons just carries a
.desktop file for the panel applet). Instanciation should be
retooled to do lazy-loading.

The VDG has offered to join in with some cool mockups to maxi-
mize potential.


As a closing note, since we're dealing in engineering issues
much of the day, we're sometimes very heavily habituated to
react to proposals with a mindset of scanning for "what's wrong
with this". This is an excellent mindset to adopt for code
review, but it's pretty awful for product evolution. A mix of
"what's right about this" or "what motivates this" works much
better.


Cheers,
Eike