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
