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
