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
