Evolving Appdash

[Eike Hein]

On 12/15/2015 08:11 PM, Martin Klapetek wrote:
> I feel like this argument is not holding very well. We already provide
> KRunner
> by default, which I believe falls into the very same category as this. It's
> just another way to do the same thing (launching an app plus much more
> duplicated functionality) that not everybody uses/needs and yet has it
> loaded by default.

It's about the costs involved, which could be:

* Increasing UI complexity (from just clutter to creating uncertainty
  over which way to do something is the 'right way for me')
* Resource usage


In the default desktop KRunner has some costs when you don't use it:

* It's visible via several Run Command actions distributed over the UI)
* It's a permanently running process, not started on demand


For Appdash it would (presumably) be:

* A Toolbox entry (which might not be shown on a non-touchscreen
  device based on notmart's thinking)


But yeah, the evolution of KDE's Run Command dialog into a permanently-
running search-anything launcher UI is indeed a good example of
"different UI for different frame of mind" even in the context of no
form factor transformation.

During the IRC discussion, it was brought up that the Plasma way of
addressing this is broadly to let you swap out shell components for
alternatives. This doesn't address cases where you want the UI change
to be additive (i.e. provide both shell components at the same time),
though.

The only way we have for this right now is adding widgets, which
imply a permanent visual delegate, which is undesirable in case of
Appdash (see the user bug report).

Adding Appdash to the default cabal of components doesn't address
this meta-problem - but even if we come up with a solution for it,
defaults still matter.


Cheers,
Eike