plasma search in application launcher?

Duncan 1i5t5.duncan at cox.net
Sat Sep 22 04:01:26 BST 2018


Kristian Rink posted on Thu, 20 Sep 2018 11:50:20 +0200 as excerpted:

> thanks a bunch for your response and taking the time writing such an
> in-depth explanation. Greatly appreciated. :) I'm still in the process
> of getting used to KDE Plasma and, so, also learning how these things
> fit together and how they are named, so hope you pardon me messing up a
> few terminologies here. ;)

Not a /big/ problem.  In fact, in many cases (including plasmoid/widget) 
the generic name is what the UI uses and what is recommended for normal 
usage.  I just have a bit of a personal "peever" problem with "impossibly 
generic" terminology, as I suppose I hinted with the complaint about the 
generic "Application Launcher" name, because when there's alternatives, 
as there inevitably are in Linux, generic names are frustratingly unclear 
and often require an additional round trip of support discussion to be 
sure what people are actually referring to.  With a unique name at least 
it's clear what people are referring to.  If felt necessary, people can 
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).

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.  Tho at least in the non-plasma environment the name is 
(was?) normally extended to "KDE system settings" (maybe it's plasma 
system settings now?  I don't normally use other desktops, just (a 
somewhat slimmed-down, no semantic-desktop, etc) plasma so don't know), 
so that's the term I've pretty much settled on even for the kde/plasma 
context.

At least kde/plasma seems to do better at this than gnome, with their 
impossibly generic "Files" and similar apps...

So anyway, my general rule has become to mention both terms at least once 
in the reply, and then use my preferred, generally less generic, term.

More reply inline...

> On 9/20/18 9:04 AM, Duncan wrote:
>> 
>> It's not entirely clear from your description, but I /believe/ what
>> you're referring to here is krunner, the beefed-up "run dialog" that
>> does so much more these days.
>>
>>
> Yes, as far as I learnt by now, this is indeed krunner. It has an
> *impressive* feature set for sure, and I'm just slowly adopting its full
> potential for my day-to-day workflows. Started using KDE once again
> after spending most of my FLOSS life on GNOME or XFCE, I really quickly
> managed to make myself feel comfortable with the environment except for
> that one use case missing, in the Application Launcher (kicker):

Glad you like it! =:^)

> When searching for an application in there (like Firefox, konsole,
> Thunderbird, ...), I'd like to be able to switch to an active instance
> of these applications if there are any, rather than starting a new one.
> krunner can do that apparently (and much more). The other way 'round
> however, krunner apparently doesn't offer a way to lock screen or
> shutdown the system; otherwise I'd completely give up on the start menu
> and just use krunner. But maybe there are still better ways to set all
> this up. Still learning. ;)

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]

FWIW, the default "Task Manager" plasmoid (aka taskbar, tho it's just the 
one component of the default panel aka taskbar container) is supposed to  
have support for switching-to-vs.-launching.

Tho I don't personally use it, preferring other app-switching methods 
such as focus-follows-mouse, tho admittedly that works best on a larger 
desktop[2], and the keyboard-based alt-tab (which on plasma has several 
possible switchers, with a second 'active' one configurable using a 
second set of keyboard triggers as well), or occasionally some other 
alternative (the window list, configured here to popup with a third-
button click on the desktop, or grid-view or the cube desktop switcher, 
invokable with keyboard shortcuts, customized to win-c=cube and win-
g=grid, here).  Thus the "supposed" above -- I don't know how it works in 
practice as I don't use it, but I frequently read about it in the git 
logs, which I track because I run the live-git versions, and know about 
the feature from that.


Meanwhile, for sleep/hibernate/reboot/shutdown at least, if you know the 
CLI command to do it, should be able to simply run that from krunner.  
And logout /should/ be available from one of the existing runner, it is 
here.  Tho obviously you'll need to have that runner configured as active.

Tho again, multiple ways to do it.  For shutdown here, I actually have 
the ctrl-alt-delete shortcut set to invoke logout, immediate, without the 
usual 30-second delay.  And since I actually run kde from a CLI login 
using startx (with startkde set as the X session), that returns me to the 
CLI terminal, where pressing it again is configured to trigger systemd to 
initiate a reboot.  (I don't normally use hibernate, etc, so don't have 
that configured.)

And there's the Leave... option (configurable, of course) available from 
the desktop menu (by default right-click or I believe long-touch, on the 
desktop).

> Actually I filed a feature request (I hope) for that, here:
> https://bugs.kde.org/show_bug.cgi?id=398859
> 
> Let's see what happens...

I see it has been marked a dup of other requests to allow an expanded set 
of krunner plugins to run (existing whitelist, get rid of that and maybe 
make that a blacklist if there's a technical reason not to list every 
single one).

So it actually already does the krunner thing, but has a whitelist so as 
to hopefully block out stability issues and prevent both krunner and 
plasma-shell from dying at the same time, which I mentioned as a 
deliberate policy in the previous reply.

But with plasma5 now reasonably stable and mature, either whitelisting 
more runners or switching it to a blacklist and restricting fewer 
plugins, may indeed make sense.  Echoing your thought, we'll see what 
happens...


Tho in keeping with multiple ways to do it, I don't really use the 
kickoff (or alternative launcher plasmoids) that much myself.  What I 
normally use as a launcher is a bit of a long story starting with having 
a keyboard with a bunch of "extra" keys on it.  Looking back after 
writing it here it's probably actually /too/ long and I'm sure looks 
crazy, but WTH, I've already written it, and you or some other reader 
might find it interesting, so...


In the kde3 era I had configured khotkeys to use those in combination 
with other keys to effectively give me a bunch of mini-menus if I paused 
after the first key, or direct-launch most of my commonly used apps if I 
used them enough to remember they launch-key sequence.

Then kde4 came along, and well before it was properly stable and mature, 
the kde folks dropped support for kde3, and I was left trying to find 
alternatives for formerly working functionality in kde3, that was still 
very broken in kde4.  As it happens, key-sequence launching like kde3 had 
never /did/ get fixed properly in kde4, with the devs blaming it on a bug 
or lack of functionality in qt4.

But I *liked* my keyboard-triggered launchers, I had too many things to 
launch to fit them all on individual keys, and remembering complicated 
ctrl-alt-shift-win-KEY sequences without some sort of popup menu 
reminders simply wasn't working for me when I tried it for a bit.

After trying a few third-party alternatives, most didn't allow the 
sequencing I had gotten used to, and the one exception I could find, 
xbindkeys, only supported it in an advanced mode that required learning 
scheme/guile in ordered to program.  Which given I was reasonably 
determined I might have done, except for two things:  (1) All sorts of 
stuff was still broken in kde4, so this wasn't the only thing I was 
having to scramble for workable solutions for, and (2) about an hour into 
reading the xbindkeys documentation to try to figure out where to start I 
had a realization -- instead of treating each key sequence as 
indivisible, I could use a recursive setup where the first key launched a 
selector menu that would then trigger on the second key, which if 
necessary could launch a nested selector to trigger on the third, etc.

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. =:^)

These days, after a few generations of reconfiguring the menus, my 
primary menu has these five letter-options a=app c=config f=file g=file 
n=net, which will invoke the script again with the appropriate secondary 
menu.  Alternatively, given that my keyboard has enough extra keys, I can 
launch each of those five secondary menus directly with their own single-
key launchers if I like, skipping the top-level menu.

So to launch for example kpat, it's either launch g p (Games Patience), 
or games p.  Palepalli (the puzzle game) is launch g P or simply games P 
(caps P, as opposed to small p for kpat).  To launch the default browser 
(recently switched from firefox to chromium, but because I had the 
foresight to setup a shell-script as my actual default browser and invoke 
it to run whatever was the actual default, it was just a matter of 
pointing it at the other one) with my bank's web page login, it's either 
launch n ctrl-b or simply net ctrl-b, while launching claws as my mail 
app is launch n z m (Net z=other, Mail) or net z m .

I have a reset submenu under config, so to restart krunner, it's either 
launch c r r (Config Reset kRunner) or config r r .  To restart plasma-
shell, change that last r to a p .

I have a hotkeys-menu editor submenu, so to edit the games menu, it's 
config h g (Hotkeys Games) or launch c h g.  That invokes mcedit in 
konsole to edit the text-based games menu config file.

The point of all that being... I use my custom key-sequence launchers for 
anything launched often enough to justify putting it in one of the 
launcher menus and picking an appropriate mnemonic for it, and I use 
krunner for launching other things not commonly used enough to have on 
the menu, but still commonly used enough to remember the name to type.

That leaves the default launcher sitting there mostly unused, unless I'm 
bored and looking for a different game to try, or otherwise actually need 
to browse the applications menu to find what I want to launch.  For this 
reason, and because the default launcher is good /enough/, I haven't 
really played around /too/ much with the alternative launcher plasmoids 
out there, tho I know there are several, and I've even tried a few for a 
few minutes when I was bored.

>> As for that wide array of search sources... krunner has a search-plugin
>> architecture just as plasma-shell has its plasmoid-widget plugin
>> architecture, with all sorts of runner/search plugins available to
>> search the various sources (running windows/desktops/activities, web
>> shortcuts, various indexed-file results from the semantic-desktop index
>> components that I don't have installed here and thus don't get, units
>> converter, all sorts of stuff!).
>> 
>> 
> Yeah this is pretty amazing. Currently and very cautiously looking into
> that, I wonder how much effort hacking in custom search providers would
> be, even though my language skills (mostly Java, a bit of Python)
> possibly won't suffice for that... :) Still an interesting new
> playground...

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.  This is a change from kde4, where 
qtscript (and qtquick, an earlier version) were generally available but 
less mature, so most plasmoids were written in C++ and loaded as shared-
object (*.so) libraries, and there's still a few C++ *.so binaries, but 
they're gradually getting ported to qtscript, enhancing stability and 
maintainability in the process.  Some still have native code for bits and 
pieces, but more and more it's qtscript.

FWIW, the same goes for kcontrol modules (which they're still called 
despite the app itself being the impossibly generic system settings).  
Plasma's in the middle of (slowly, one or two at a time over some years) 
modernizing and updating them, and porting them to work in a plasma-
wayland session as well as in plasma-X, and the rewrites tend to be 
mostly qtscript, calling functionality in native code only where qtscript 
doesn't (yet) expose the required functionality.

Similarly, kwin's effects are being rewritten into qtscript, with custom 
native code only where it's necessary, and even then, they often make 
that native support generic, put it in a general support lib, and expose 
it to qtscript, so the "effect" itself is entirely qtscript.

So knowing java and python, and presumably having picked up some web 
technology as well and with it javascript, you may well find writing your 
own or simply hacking existing qtscript-based plasmoids, kwin effects, 
and kcontrol modules, surprisingly easy. =:^)

---
[1] KDE store and downloads integration:  This got big in the kde4 era 
with the first couple generations of integration, with kdelook.org, kde-
apps.org, etc.  But that was a third party and coordinating to integrate 
new features and changes was always a problem, so apparently at some 
point they decided to setup their own, kdestore.

This "different users operate differently, and there's many possible ways 
to do it, so let's have a sane default but let the user decide, and 
encourage a healthy user-extension ecosystem while we're at it" attitude 
is one of the big reasons I've stayed with kde/plasma.

[2] Larger desktop:  Here, after upgrading my multi-monitor setup 
steadily over the years, I now run with a /huge/ desktop of two big-
screen-TVs as monitors.

The primary monitor is a 65"/165cm 4k/3840x2160 TV, with a 48"/122cm 
FullHD/1920x1080 TV as secondary.  I'll often have youtube or the like 
playing full-screen on the 48" (as it is right now, minitube playing from 
the VideoPhixa youtube channel, female vocal trance mixes, etc), while I 
work on the larger 65" 4K.

I have a moderately large set of kwin's window rules setup to standardize 
most work windows to a 1280x1080 size, thus allowing a 3-wide-by-2-high 
grid of standard-size 1280x1080 windows on the 4K.  (Tho messaging client 
windows such as mail and feeds on claws-mail and nntp/news on pan, are 
double-width, 2560x1080, giving me ample room for the standard mail/news/
feeds 3-pane UI, with the panes side-by-side in the 2560px width.)

Which gives me room for six work-windows plus the full-screen/full-HD 
video-player window, all displayed without overlapping.  On that sort of 
layout, focus-follows-mouse is a rather effective window-switching 
method.  Couple that with three virtual desktops to group the windows on 
and scrolling over the desktop set to switch virtual desktops (tho that 
does imply leaving one of those six slots open), and I could /only/ use 
focus-follows-mouse, if I needed to.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman





More information about the kde mailing list