plasma search in application launcher?

[Kristian Rink]

On 9/22/18 5:01 AM, Duncan wrote:

[Terminology]

[...]
> use both, referring to for instance "the dolphin file manager" 
> instead of simply "dolphin", but IMAPO (in my admittedly peever 
> opinion) at least, just "dolphin" remains better than an impossibly 
> generic "files" (the corresponding gnome alternative).

Fully agree. However, coming "from the outside" it's rather difficult, 
in most cases, to figure out *what* exactly the right name is. In 
example, talking about the KDE panel "application launcher" menu, I had 
quite a time figuring out what it actually is. Even worse so about the 
search window which I initially just referred to as "the search window 
triggered by ALT+TAB" because I didn't have the slightest idea which 
component is in charge of that.

 From that point of view a partially understand the way GNOME guys do 
it: Try to find a common terminology between users and developers which, 
for a user, makes it impossible to use a "wrong" term for something and 
still enables the developer to figure out what on earth the user's 
actually talking about. ;)


> As another example I really hate the decision to use the generic 
> "system settings" name as well, /far/ preferring the kde3-era 
> "kcontrol", particularly given that it's mostly kde/plasma settings 
> found there, not actually /system/ settings, and where it /is/
> system settings, it's the kde-based configuration UI for them, not
> for example the CLI or gtk-based alternative.  

I'm pretty torn about "System settings" as a name to be honest. From one 
point of view, indeed you're right it seems a pretty strange name as 
these aren't really "system" settings but mostly desktop-related things 
and the "system settings" name mainly seems to stem from Windows or 
MacOS "System Settings" dialogs which actually do far more than just 
desktop stuff.

On the other side however: Current Linux desktop "System Settings" also 
*do* have system aspects in it (such as WLAN, Bluetooth, Printer 
configuration and the like, or the systemd addin for configuring system 
services). Maybe there's a gap here, too, between functionality and 
actual user expectation - but that seems increasingly off-topic here I 
guess. ;)



> 
> The one thing that kde/plasma tends to do more than some others, is 
> customization, and often providing multiple alternatives, such as the
> deliberately flexible plasma widgets/plasmoids setup with some 
> shipped plasmoids, but also deliberately encouraging other people to 
> write more and put them on the kde store, as well, often with 
> integration directly into kde apps to download more alternatives
> from the store.[1]

True. I'm still a bit overwhelmed by all the options to be honest. It's 
nice to see, though, there is a load of configurability for many 
different aspects of the desktop; this indeed seems a total strength of 
KDE in general and possibly always was. This is bit of a difficulty to 
deal with as well: Coming from a different desktop, one's possibly 
tempted to "imitate" a load of settings that used to be around before 
rather than figuring out what would be "The Preferred Way" of doing 
things where one is, now. With all the options at hand, in KDE, it 
sometimes feels a bit difficult to figure out what *actually* might be 
the way things are intended to be used - there rather doesn't seem to be 
*the* intended way as such. ;)

> 
> It was that realization that finally gave me a workable, for me, 
> solution.  While not normally a GUI language, I already was 
> reasonably proficient in bash/shell scripting, and what I ended up 
> with was using a single khotkeys configured trigger to run a bash 
> script in a popup konsole window, with that script loading a menu 
> configuration file and taking exactly one (optionally modified) key 
> as input.  That key would select the appropriate line from the menu 
> config file, which would tell the script what command, possibly a 
> nested trigger of the same script with a different/nested menu, to 
> launch.
> 
> It's a bit crude but it works.  And because it's primarily my own 
> shell code and menu configuration files, when kde5/plasma5 came 
> along, I only had to modify things slightly to keep it all working
> on plasma5. =:^)

Wow that *is* quite a workaround. :) I'm at some point amazed however to 
see you even made the switch to post-KDE3 rather than following the 
"former" KDE3 crowd to using and maintaining Trinity as a desktop 
environment. Actually, I had a similar history but changed a bit all 
along the way: Used KDE and GNOME more or less in parallel during their 
"early" days (pre-1.0 era), a bit more GNOME than KDE after that, and 
XFCE for a long period in between. Before KDE and GNOME (early desktop 
Linux as well as SunOS), I did way more tweaking to my X11 desktop, too, 
but at some point got a bit bored of that - most of the time I used to 
have one or several xterms (or other terminal emulators, later on) 
opened anyway so there was little point in using a menu system while 
most of the time each application I needed was just a CLI command away. 
Consequently, I usually had some fast-reachable key binding (ALT+ENTER, 
most of the time) set to launch a new terminal window... ;)

This only "really" changed with GNOME3 to be honest: In GNOME3, the 
"dash" overview workflow essentially was what replaced my workflow with 
multiple open xterms. Plain and simple: Press left "Windows" key leaves 
you with the dash overview and the "search bar" focussed, where you 
could enter some text and either find applications to run or find open 
windows to switch to. Dead-simple and works like a charm for most of my 
requirements without too much ado. This is what I do in KDE with the 
plasma search bar now - as this (same as GNOME dash) actually gives me 
an advantage that justifies using a desktop environment over a simple 
window manager, after all: It introduces things such as searching 
multiple sources (finding files, contacts, websites, ...). I'm still 
very keyboard-centric most of the times, and the search bar has replaced 
the terminal/CLI for most use cases... :)


[Plasma search]
> 
> With java and python as background I suspect you may be pleasantly 
> surprised.
> 
> Most plasmoids are now written in qtscript, a javascript-like 
> scripting language with qt extensions, of course with a few further 
> plasma-specific extensions as well, for plasmoid use.  

Interesting. Guess I gotta take a dive into this. Actually I've been 
playing around with python-qt a bit so far, mostly in order to find a 
cross-platform desktop application development environment that is not 
Java and not *cough* electron. Maybe dealing with the KDE developer-side 
guts ain't too bad a thing either, especially given most of my current 
working days lacks a bit of the technical challenges in terms of looking 
at or writing code... :)

Anyway, thanks loads for your input, greatly appreciated!
Cheers,
Kristian