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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
