plasma search in application launcher?

[Duncan]

Kristian Rink posted on Tue, 25 Sep 2018 13:48:16 +0200 as excerpted:

> 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. ;)

[Second attempt at a reply, as the first just got wayyy too long and 
meandering...]

FWIW, the biggest problem I had identifying krunner in my first up-thread 
reply wasn't "proper" name confusion, but rather, a different generic 
name than I expected coupled with a different keyboard shortcut.  "Run 
dialogs" aka "open dialogs" are reasonably well known and universal terms 
due to their long history and broad implementation across many 
platforms.  While these days due to auto-completion functionality they 
tend to function as search dialogs as well, they really do trace their 
history to early popup run/open dialogs from well before auto-complete, 
when you actually had to type in the whole name of the app or document, 
no auto-complete, and simply the fact that it could "magically" infer 
from the document type what app to open to handle it, due to file 
association, was the big new thing.

But perhaps the "search window" thing comes from the gnome side?

The second point of confusion was the mention of alt-tab as the shortcut, 
while the default is alt-space (I looked it up), and was alt-F2 in 
earlier kde versions (with alt-F3 opening the window menu and alt-F4 
closing the window), and alt-tab is often used as the window-switcher 
shortcut as that's what it was on MS.  That was the historical default on 
kde as well, and I thought it still was, but it turns out there's now 
apparently no default shortcut associated with the window switcher (in kde 
system settings under shortcuts, global, kwin, walk through windows 
action).

So I'm not sure where alt-tab to open the run/open dialog (krunner) came 
from unless you or your distro customized it, but I would have expected 
alt-space or alt-F2 for that, and between the alt-tab pointing to the 
window switcher for me, and the fact that I'm not used to the run/open 
dialog being called the search window, I was uncertain what you were 
referring to, tho the functionality described sure appeared to match 
krunner aka the run dialog aka the open dialog, now with a new-to-me aka 
added, the search dialog/window.

Once I had that figured out, the application launcher (kickoff) plasmoid/
widget was what was left, tho with multiple widget/plasmoid alternatives 
there, the only real way to identify which specific one you're referring 
to is to either use the proper name (kickoff, kicker, etc), or be 
extremely careful to use /exactly/ the generic UI name (application 
launcher).  Well, either that or be sufficiently familiar with the 
differences in behavior of each one compared to the others to know it 
from the description (FWIW, I'm /not/).

>> 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.

> 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. ;)

FWIW I covered the actual system settings found there bit with the "it's 
the kde-based config UI for them", as opposed to the CLI or gnome or 
whatever config UI for them...

Tho I guess as they say, by now that ship has long since sailed... but 
that doesn't mean I have to /like/ it!

> 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. ;)

Indeed, to the extent that there's an "intended" way, the kde devs try to 
make that the default.  But arguably (and I believe as it should be) 
they're more concerned with making the default a functional lowest common 
denominator usable by all, not seriously objectionable but perhaps not 
ideal for most either, that can function "well enough" until the 
individual user figures out what they want and gets around to changing 
the config appropriately, then they are about defining some single 
"intended-to-be-perfect-for-everyone" way, because arguably that's simply 
not possible.


>> [Custom-hacked sequential hotkey menu solution, hacked together from
>> bash scripts, various CLI helper utilities, konsole and a custom 
>> konsole profile, a custom kwin window rule, and a single trigger
>> hotkey.]
> 
> 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.

Fortunately or unfortunately, trinity was a bit late to the party for 
that.  By the time it really got going, kde 4.5 was out, and I'm on 
record as saying 4.5 is what /should/ have been 4.0, with 4.2 and earlier 
being alpha previews, 4.3 being beta, and 4.4 the rcs.  In fact, 4.5 was 
not only what should have arguably been 4.0, but 4.6 was actually much 
worse than 4.5 due to konqueror bugs and the kdepim stuff jumping the 
akonadi shark and not stabilizing again until far later, possibly 4.9 or 
4.10.  (I don't actually know personally as I needed an email client that 
actually worked, and kmail wasn't it during the early akonadi period, so 
I had to find an alternative for it, and akregator the other kdepim app I 
had used, too.  FWIW, claws-mail for both, tho I take pains to run them 
as separate profiles because I like to keep my mail and feeds separate, 
as I do my news(nntp) with pan.)

I was trying to upgrade to kde4 in the late 4.2 and early 4.3 time frame, 
when kde devs were insisting it was ready for normal use, but it was 
still very very broken.  And trinity wasn't really available until 
later.  Couple that with the fact that the gentoo/kde devs weren't 
interested in trinity, and no other gentoo devs were either, so it never 
got mainline gentoo packaged meaning I'd have had to either try from the 
kde-sunset overlay or handled all that myself, and I never tried it.

> 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 is one spot where my earlier attempt at a reply really derailed...  
Trying to keep it reasonable this time...]

After earlier Linux experiments that went nowhere primarily because I 
wasn't yet comfortable with it and didn't yet have the motivation to 
invest the time to /get/ comfortable, MS provided me that motivation with 
eXPrivacy, which I could clearly see going somewhere I simply wasn't 
going (with the ultimate result being what we have today as MS windows 
10).

It took me three months to switch, during which I first read the 600+ 
page Running Linux nearly cover-to-cover in ordered to get the 
understanding I was previously lacking, then started what I knew had to 
be a permanent switch, with the goal being to establish myself as a power 
user reasonably on par with the level I had on MS after nearly a decade, 
because I /knew/ that was the only way I'd actually stick with it.  Keep 
in mind that I had been a VB-pro level programmer on MS, had run the IE4/
OE4 thru 5.5 betas and was active enough in the MS newsgroups that at one 
point I was considering MSMVP (tho that didn't last long as I began 
investigating Linux about the same time), and had an MS desktop 
sufficiently customized with various apps and utilities including some of 
my own that a number of people said they initially had trouble believing 
I was running MS.

Specifically, on Linux I wanted multi-monitor and a few other things 
either working to my satisfaction, or be able to point to concrete 
reasons why it couldn't be done on Linux, to my satisfaction.

In that three months, I not only chose my desktop and basic apps, as most 
users would do, but got comfortable running kconfig and building my own 
kernels from sources, figured out the difference between proprietary and 
native Linux drivers and that I unfortunately needed the proprietary 
nVidia blob drivers for multi-monitor (I had checked Linux compatibility 
when I bought the card previous to the switch, but didn't know the 
difference at that time and thus didn't realize the hole I was digging 
for myself, a mistake I eventually rectified with an upgrade to Radeon 
hardware, which I've stuck with since), learned how to configure xfree86 
with the proprietary driver and multi-monitor, learned (then) LILO and 
how to use the BIOS and LILO to multi-boot MS to or Linux, and...

Over a few more months, I learned both bash and the (mandrake) linux boot 
sequence by rewriting the core initscripts to my liking.

Suffice it to say I achieved my goal and then some, learning more about 
the Linux boot cycle (among other things) than I ever knew about MS 
Windows, and becoming sufficiently comfortable on Linux that at the three 
month point I found myself booting to the MS side to do something or 
other and then sitting there, wondering what there was to actually /do/ 
on MS, just like I had been sitting there on the Linux side wondering 
what to do with my earlier Linux experiments and up to just three months 
before, when MS basically pushed me off them and I realized I needed to 
be on Linux, permanently.

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

Reading that, I can suggest looking into the "application dashboard" 
plasmoid alternative to the "application launcher".  The application 
dashboard is a full-screen alternative that I believe (having never used 
gnome and its dash) to be plasma's dash parallel.

You can either install it as a new plasmoid/widget, keeping the existing 
application launcher, or swap out using the "alternatives..." 
functionality, available when widgets are unlocked by right-clicking the 
launcher icon and choosing alternatives.

I've experimented with application dashboard for a few minutes several 
times, but didn't find it to my liking for permanent use, I suspect 
because it simply looks ridiculous on a big-screen monitor, tho I equally 
suspect it might be great on a small-screen phone UI or similar.

You may or may not find it permanently usable, but if you're like me, 
even if not, you'll be glad you spent the time at least figuring out at 
least what the option was and how it worked.

And given that you're coming from gnome and dash, I'd be interested in 
reading your opinion of it, and how it compared/contrasts.


As for xterms, etc... [another spot I meandered off on the first 
attempt...]

Being on gentoo and thus (scripted) building from sources, I typically 
have 2-3 konsole windows open for my updates, and I've found I prefer 
terminal windows for most other maintenance including text editing (mcedit 
for both user and system files), file management (mc or CLI) etc.  The 
natural exception is media files, where I use gwenview for images and 
video, leaving dolphin not much used except for audio and as a glorified 
file-open dialog, and an X-based text editor (kwrite, kate, etc) not even 
installed.

One thing that recently changed for me, with the upgrade to the 4k/65-
inch, was that with the 1280x1080 standardized-size konsole, browser, 
etc, windows, allowing six standard-size windows in a 3x2 grid without 
overlap, is that for the first time in my life, I feel like I have more 
screen space than I actually need or can make efficient use of.  The six 
unoverlapped working windows on the 4K is a **HUGE** change from the two 
smaller 960x1080 windows I could fit on the full-HD, and it makes 
**MUCH** more of a difference than I expected it to.

Anyway, it's nice being able to have 2-3 konsole windows open doing 
updates or other maintenance, plus the ksysguard window graphing system 
metrics like CPU speed and usage, memory usage, fan speeds and system 
temps, net usage, etc (nice to monitor system usage when I'm doing those 
builds!), plus a browser window or two and/or a feeds/mail/news window... 
plus the media player full-screen on the secondary monitor...  and be 
able to switch between them all with focus-follows-mouse by simply moving 
it to point at whatever window.

I don't know what your monitor situation is and you may well be mobile 
far too much for this to be practical, but FWIW, if you get a chance to 
try a decent sized 4K monitor/TV, at least 55"/140cm and preferably 65"/
165cm or above, I think it's an experience any avid multi-window computer 
user needs to have at least once, and it may be worth considering the 
investment, because it really /does/ make quite a difference -- that's a 
**LOT** more screen real estate than was generally possible in the past, 
and you really do have to try it to truly appreciate what actually having 
enough screen real estate to have a good half-dozen windows open without 
having to Z-order stack them does to your computer working potential.

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

FWIW as you mention cross-platform...  It's worth noting that just as qt5 
is modular these days and you can pick and choose only the modules 
necessary for the functionality you need, so kde-frameworks-5 is designed 
with the same goal in mind.  Additionally, being built on qt5, the 
frameworks functionality tends to compliment it nicely, so it's possible 
to just choose the framework(s) necessary for that extra bit of 
functionality that qt itself doesn't have.

Between that and both qt5 and kde-frameworks5 being cross-platform, with 
many modules available for use on MS and Android, it's a really flexible 
environment to work with.  Add to that qtscript... Tho AFAIK many of the 
plasma scripts assume other bits of plasma so they probably won't work 
out-of-the-box on other platforms unless plasma's on the platform as well.

It's quite a different picture from the days when both kdelibs and qt 
were effectively monolithic, if you wanted part of the ecosystem, the 
rest came along for the ride whether you wanted/needed it or not, 
tremendously bloating either the app itself for static linking, or at 
least the dependent libs for dynamic.

-- 
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