Web lists-archives.com

Re: plasma search in application launcher?




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