Re: plasma search in application launcher?
- Date: Thu, 27 Sep 2018 12:12:54 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: plasma search in application launcher?
Kristian Rink posted on Thu, 27 Sep 2018 08:22:40 +0200 as excerpted:
> Hi again;
> actually, is this still a public, "active" list, by the way? Thought it
> would be sort of a KDE user forum / support channel but it looks like
> we're the only ones communicating in here. Nevertheless:
It's still public and what I'd call semi-active, but relatively low
traffic these days. Seems most people prefer web forums or IRC/chat.
But there's still a few people asking questions and regulars providing
answers where they can.
While I'll do web forums occasionally I prefer lists or newsgroups, and I
stay away from the "instant" stuff pretty much entirely as my style is
too deliberative and my prose too long for that (tried it, regretted it,
stay well away from it except for after-the-fact reading the occasional
IRC meeting log these days).
FWIW I'm actually old-school enough to prefer newsgroups (nntp), and I
handle nearly all of my mailing lists including this one as newsgroups
via news.gmane.org's list2news service. While the gmane web side was
transferred and the new owners effectively abandoned it, Lars still runs
the news side that forms the list2news service, and that's what I use.
For people just starting with gmane, however, while reading should work,
last I read the system that mail-back-confirms addresses for initial
posts to newsgroups/lists wasn't working reliably, so replies via gmane
likely won't work and the workaround of mailing replies direct to the
list instead of replying to the "newsgroup" and having gmane forward
them, would need to be used.
So anyway, I actually see and reply to the posts via the
gmane.comp.kde.general "newsgroup" on news.gmane.org, and I do that for a
few other lists/groups as well. Maybe that's why I'm still around
myself, as once I'm checking "newsgroups" for new posts anyway, it's
hardly a bother checking one more relatively low-traffic group.
> On 9/26/18 10:08 PM, Duncan wrote:
>> So I'm not sure where alt-tab to open the run/open dialog (krunner)
>> came from unless you or your distro customized it
> Well that, apparently, is solely to blame to my dumbness of not being
> able to write what I actually mean, in this situation. Of course it's
> ALT+SPACE, on my device, as well. ALT+TAB indeed opens the window
> switcher. So this one's completely on me, sorry for the mess-up. :| I
> should be more careful.
Mystery solved, then. Thank you!
I was beginning to wonder if some distro was customizing it, and
wondering what else they might be changing that would end up being posted
here to confuse me and anyone else trying to respond, particularly since
I couldn't really figure out the logic behind using alt-TAB, with its
already well established window-switcher usage, which implied whatever
else they might be changing might have similarly "tilted" logic!
So it's actually quite a relief to read that was actually a mistake, not
someone screwing with shortcut defaults for who knows /what/ reason, that
we'd be dealing with in other threads!
[CLI vs. GUI config interfaces]
> I always hated it
> when, back then on an earlier Debian installation, I always *had* to
> launch a terminal or to fiddle with the command-line openvpn to connect
> to our corporate VPN. It worked, but it repeatedly got into my way and
> just "felt" strange on a graphical desktop. For these purposes I like
> wicd or NetworkManager; I don't want to think too much about all this.
Heh, I can see myself getting tired of that too, scripting it up, and
setting up a new menu item on the custom menu setup to do the connection
for me. Or putting the script in the boot or plasma startup sequence if
I wanted it running pretty much all the time.
(Which BTW brings up a different point. I don't run a *DM graphical
login at all, preferring to boot to a CLI login, then run startx with
startkde set as my xsession. So while something set to run at plasma
startup might be considered running at boot for some people, it's an
entirely separate thing for me. I only run X/Plasma when I want the GUI
running, which admittedly is most of the time, but not always,
particularly when I'm doing system maintenance, and I'd have to login
either way, so for me it's just easier to do a CLI login and run my kde/
plasma start script when/if I want to, even if that's immediately after
login, most of the time. So yeah, running X/kde/plasma isn't something I
consider part of the boot process, here, tho I recognize it might be, for
> Likewise, talking about configuration, I never really understood why I
> should have a GUI based program that requires interaction with text
> based configuration files in order to set it up right (and eventually a
> manual restart to actually apply any settings changed). I know it's a
> matter of taste, and I also know a load of people who are perfectly fine
> with this, but, well, I'm not. ;) If, in example, on a desktop I want to
> be the task bar on top not on the bottom, I want to be able to "drag" it
> there (using mouse or touchpad) rather than opening a config file, write
> something such as "taskbar_position: bottom" and restart my desktop.
In the "wild" reply I deleted instead of sending, I had mentioned that
back in 2001 when I was first choosing a desktop, that being the gnome1
vs. kde2 era, it quickly became obvious to me which desktop I wanted,
when I realized gnome didn't even include a proper color-settings
applet! Instead, they expected you to choose from pre-existing themes,
and if you didn't like one of the individual colors, you had to manually
text-edit the theme to change it!
But even the proprietary MS I was leaving behind had a GUI color settings
applet that let you change individual GUI color elements!
Needless to say, I pretty quickly dumped gnome for kde, which *did* have
a color settings applet that let you set individual GUI color elements,
But to this day, that's what I think of when I think of gnome, updated
today with the whole early gnome3 "you get what we give you because it's
the 'proper' way, and no argument!" fiasco. Even when the kde devs were
insisting the still very broken kde4 was working, because it happened to
work for their setup and they apparently hadn't tested the other options
the people experiencing breakage were using, they weren't insisting that
it had to be their way ONLY.
And even when kde4 was broken and they were insisting it wasn't, tho they
had unfortunately already dropped support for the still working kde3, I
could see fixes slowly going in. So I stuck with it, because I believed
in what it could become once again, a desktop where alternatives actually
worked, as opposed to one where the devs insisted there were no valid
So I obviously have some strong feelings on being able to use a GUI to
configure a GUI, as well. Tho equally, I'm glad text-based config files
remain a thing, allowing manual text-editing the config, when it does
become necessary, whether that's because the GUI is bugged and broken
until the offending buggy setting can be removed via text-edit (remember,
I'm running live-git-based plasma here, and it does occasionally happen),
or when the changes involved are massive and the GUI only allows changing
one thing at a time but you need to change fifty. (The last time I
remember that happening was when I was switching from kmail to claws-
mail, and I had a whole slew of incoming mail filter rules to setup on
claws to match the ones I had in kmail. A direct import wizard would
have been nice but wasn't available, but I found that after setting up a
single rule of each type in claws as a pattern, it was far faster to text-
edit the filter-file to setup the rest, than it was to add each filter
individually via the GUI. If the filter file was some binary format I'd
have had to do them all via GUI one at a time. <shudder!>)
It's also nice to be able to "grep" things to change, whether you're
actually using grep at the CLI (or in a script), or using a GUI or semi-
GUI (like mc with its file-search, which I prefer to a full GUI file-
search these days).
> But: Throughout the last two decades, I have seen quite a load of FLOSS
> desktop applications that used right this understanding to completely
> give up and not even remotely think about usability, interface
> guidelines and all those things at all. That's, like, "you can't make it
> right for everyone so make it in a way that everyone has to configure it
> to be usable". I see that the GNOME and Elementary guys are spending
> quite some time trying to be useful for a "non-technical" target group.
> KDE (using the Neon distribution by the way), right now, seems to be
> pretty much targeted at users who have prior experience with the
> look-and-feel and interaction ideas found in Windows. Which is okay if
> it serves as a basic design and conceptual foundation.
Again something I had originally mentioned in the "wild" reply, that got
omitted in the second attempt that I actually sent...
KDE does have a HIG, and a group (I don't remember the specific name of
ATM) that OKs/vetoes/suggest-changes to potential patches before they're
committed. They pay particular attention to things like the default
breeze color/widget/windeco components, precisely because they are the
default and they want that default to look and behave in a unified way.
I found that out when I was following the plasma-devel list, with all the
pre-commit reviews, etc, for awhile.
But non-default alternatives, even when shipped with kde/plasma by
default, and /definitely/ when simply uploaded by independent users to
the kde store as the VG (or whatever it is) doesn't even have a say for
stuff in the store, get far less scrutiny and are far freer to simply do
it the way the author likes. Tho if it strays /too/ far afield (we're
still talking look and form here, not anything as drastic as security),
status may be demoted from something more core to playground or to the
store, tho in practice that tends to happen more due to unrelated human
disagreements and/or people simply wanting more independence from the
project, than it does due to being forced out.
> I guess I know what you mean. I made an attempt in late 2012 / early
> 2013, for the last time, to go "fully KDE" (including using KDE-only
> applications for web browsing, e-mail and the like). At some point I
> moved back to XFCE I guess, and I wrote a longer rant on that here:
Back in the late kde3 era was the last I tried to go full qt/kde3, as I
had only about two things that were gtk at the time. But one of them
happened to be the gtk-based pan news client, which I've been using since
I switched from MS in late 2001 and which I'm involved with upstream (not
as a coder, but as the pan list "historian" of sorts as I've been
following both the list and pan development for so long, and was at one
point about the only regular still around keeping the lights on, so
there's some deep history there), which I was both loath to give up due
to my upstream involvement, and because I don't really know of a good
alternative (knode was the offical kde alternative, but it never handled
yenc, AFAIK, and has now been abandoned, and there was another kde-based
binary downloader that was abandoned as well), so it didn't happen.
Then the early kde4 fiasco happened, and later the kde 4.6 kdepim fiasco
and konqueror bugs that made it plain that wasn't viable as more than a
toy either, and these days, the plasma desktop itself is about the only
"core" thing kde I don't have an easy replacement for, and that could be
replaced if I had to as well, so it'd be far easier for me to go kde free
And being on gentoo which makes it possible, I turn off all the semantic-
desktop stuff at build-configure time, as well as all the policy-kit,
udisk, etc, integration, so it's a far lighter and more efficient desktop
than the default plasma.
Tho ironically, at the same time I use far less kde now than I used to,
that same development, along with the switch to git, has allowed me to
follow upstream far closer than I ever dared in the kde3 era. All my kde
stuff is built from live-git, with checks for updates and rebuilds if
necessary a couple times a week. Additionally, I routinely review the
git logs for a number of components, and as mentioned above, even
followed the plasma-devel list for a time.
Sometimes I find bugs in the new update, bisect to the commit, and file
them. The good news is they tend to get fixed now, unlike when I was
following releases and developers had moved on from that code by the time
I got it and found and filed a bug. Tho practically, the fact that I can
now bisect and report the individual buggy commit probably has a lot to
do with it too.
> Plus, also
> back then I had some applications that where GTK/GNOME based and for
> which there were no usable KDE equivalents, and GTK/KDE integration
> really sucked back then. That's something that has incredibly much
> improved recently. Right now I use KDE as my desktop, a bunch of KDE
> tools where I can (dolphin, gwenview/digikam, kwrite, okular, ...) while
> I keep applications we're internally using (Firefox, Thunderbird, ...)
> without having them feel "strange" on a KDE desktop anymore. That feels
> good, too. :)
Definitely so! The freedesktop.org common desktop specifications project
has been very good for users in that regard, as it has enabled far closer
integration of a common look and to some extent feel, to the desktop of
choice regardless of which one it is... so long as they follow the common
desktop specifications, anyway.
Actually, with kde/frameworks5 the strategy was very deliberate
modularization and integration, not only in using the common
specifications for things like *.desktop files and XDG file locations,
but even more so, in the modularization of the kde5 frameworks and in
making individual apps play well with the desktop regardless of which one
it was, as well.
It's a very refreshing change, and has a lot to do with how well the kde4/
kde5 upgrade went, as opposed to the fiasco of the kde3/kde4 upgrade.
Because everything was deliberately going modular at the frameworks level
and individual apps were being designed to integrate with the desktop and
environment where they were, with the plasma desktop in turn integrating
other apps as well, they were able to do the upgrade to kde5 an app at a
time, continuing to support kdelibs4 in deep maintenance mode so it would
continue to work with kde apps not yet ported to frameworks5. So
individual apps could and did switch to frameworks5 when their frameworks
ports were individually mature enough to do so, and it made a **HUGE**
difference in the smoothness of the upgrade compared to the 3-to-4
fiasco, which because they were *not* continuing support for the old
version, was a mass migration with many apps and core desktop components
forced to kde4 before they were even close to ready.
But from the frameworks and frameworks-based apps perspective it doesn't
matter whether you're running a frameworks5-based app on old kde/plasma4,
plasma5, razor-qt, a gtk-2 or 3 based desktop, or to a somewhat lessor
extent even MS Windows, OSX, or Android or iPhone. With the new
modularity it's possible to depend only on the frameworks and qt modules
you actually need, and the qt integration with the host platform helps to
visually and functionally integrate the app with the host platform as
That's so much different from the open-source-it-may-be but it's either
our platform and we can integrate with it, or not and we can't, that
seemed to be the way things worked before.
> Cool. I have seen very few people with such a background who actually
> dared to make a switch to Linux (or even cared enough to take a closer
It was... tough, definitely. And honestly, while I was already
acknowledging the benefits of Linux and freedomware, I don't know if I'd
have ever actually made the switch, were it not for the push MS gave me
with what became eXPrivacy and where I saw it headed, and ultimately
arrived with 10, as I simply could not and would not follow it there.
The alternatives were Linux (or the BSDs) not available would have been
dire, but I imagine I'd have gone back to spending much of my free time
in sci-fi books and TV, and would have pretty much given up on
computers. Because continuing to go where MS was very clearly headed
simply wasn't an option for me.
Computers are for me a sort of refuge from a world I can't control, a
refuge where I understand the rules and can use the power that and owning
the hardware gives me to shape my computer world to the the way I want it
to work, and MS was going to take that away, making the computer that had
been mine into theirs and effectively giving me only guest login
permissions, albeit with a few admin perms as well.
So I'm glad an alternative that let me keep ownership of my own computer
and rulership of my computer realm, Linux, was available.
So tough it was, but I understood the alternatives and that I really
didn't have much choice other than abandoning computers pretty much
entirely. After that, the rest was pretty much just the details of grunt
> Personally, I moved to Linux all along 1996, 1997, being in my
> junior years at university. Had a Wintel box running Window 95 at home
> and got in touch with HP-UX and Solaris at the university. Wanted
> something like that at home too. Got hold of a Linux installation medium
> that came with a load of documentation, the GNU Manifesto being one of
> them. For whichever reason that's one of the things I started reading
> and found myself agreeing with a lot of things in there. A lot of my
> interest in Linux in the years to follow arose from the GNU and Software
> Libre idea.
Indeed. He was probably writing it at the time so you didn't get a
change at it back then, but by the time I switched a few years later,
ESR's The Cathedral and the Bazaar was out, and I read it, finding much
of what he wrote seemed to be echos of my own thoughts. Tho he went the
open source way and I tend toward the freedomware way, in part because of
the struggles I had with the nVidia blob making the difference very
practical for me.
As a VB dev I had been running my own apps and thinking about releasing
them as free-as-in-beer, and thinking about making sources available as
well, but that was before I new about the GPL and other free and open
source licenses and I struggled with license questions and how to protect
myself should someone simply take it and claim it was theirs.
Then I found Linux and the GPL and similar copyleft and open source
licenses, and read The Cathedral and the Bazaar, and it opened up a whole
new world for me. That there was an entire and rather large community of
devs out there with thoughts similar to those I had but thought I was
alone, who had united and created a whole ecosystem of FLOSS, was quite a
discovery, and my life would never be the same thereafter.
Tho FWIW I couldn't disagree with ESR more on current events in the
community and out, but that was then and this is now, and The Cathedral
and the Bazaar group of essays was and remains brilliant, and certainly
formative, for me.
> Spent several days completely trashing my Windows installation, cleaning
> my hard drive, installing the system and reading through numerous HOWTOs
> to get most of my hardware (soundcard, ...) to work again. This sort of
> got my enthusiasm started, in many ways: On Windows 95, I had many
> situations when the system just would fail for no obvious reasons, where
> apparently re-installing was the only solution.
Here, OTOH, I really never had too much of that problem. Sure I had
crashes, and early on I made a drastic mistake when switching on MS
doublespace and lost what I had on that volume, but that was my mistake,
and other than that, I spent enough time with MS-DOS and MS-Windows
documentation, including reading very technical misc. MSDN docs I didn't
initially understand but some of it must have soaked in, as coming on
them again six months or a year later a lot more made sense, that from
fairly early on I always had a reasonable sense of what was happening and
why, and what the bugs were, even if I couldn't fix them, and how to hack
around them to make the thing work anyway.
As an example I remember one bug in I believe it was an IE 4.5 beta where
IE was now part of the constantly running Windows explorer shell, and for
performance reasons they had setup IE to direct-access the disk for its
cache index file. Then along comes the weekly scheduled defrag and moves
the file out from under IE, now constantly running because it's part of
the shell, and puts something else there. Needless to say that resulted
in cross-linked files and similar corruption, when IE wrote over-top of
whatever defrag had moved into where the index file had been.
MS "fixed" it with the next beta some weeks later by marking that index
file with the hidden and system attributes, so defrag wouldn't touch it,
but in the mean time, a lot of folks running that beta had serious
problems and some of them lost important documents that defrag had
unfortunately moved into the IE cache index file area.
But it was only a minor irritation for me, because I had $TEMP on its own
partition, with IE's cache pointed at it. So the only files it could
overwrite on my system were temp files and likely IE cache files to begin
with -- no big deal. In fact, even knowing the bug I didn't bother
changing my defrag schedule or anything, as the effect on me was so minor
it was more interesting than bothersome.
Then there was the case of the Sparq removable disk driver bug. I've
long forgotten the details now, but as I recall, the hack I came up with
to make it work involved an initial partial boot (to the CLI, not the
full W95 GUI), invoking a batch script that toggled a setting, and a warm
reboot, which didn't reset the setting I'd just toggled like a cold boot
did. I wish I remembered more of the detail to post, but that's back in
my old proprietaryware live now, and that's a life that like a defector
who will never return to his old country, I've left behind for good, so
the details really don't matter any more.
OTOH, tho freedomware, my life in the freedomware world isn't without
hacks as well. See for instance that whole menu thing I described in an
earlier post. But I'm optimistic, because more and more these days, when
stuff like that /does/ happen I can take advantage of the source, bisect
the problem, and even if I don't get a direct fix from upstream, having
bisected the problem I know exactly where it is and what code change to
reverse to correct it, and then it's only a matter of telling git to
output that commit in reverse-patch form and saving it as a patch I can
drop into the appropriate dir and have it auto-applied whenever I update
the package. (There's actually a kernel graphics driver bug I'm doing
that with right now. There was a fix for HDMI outputs, but it wasn't
applied to DVI-D or DisplayPort, which happen to be where I need it. A
bug is filed, but that was a release ago, and there has been no developer
reply since I pointed out that the fix was only to HDMI and I was running
either DVI-D or DisplayPort, neither of which had the fix. But with the
bisect I know what to revert, and a patch file is in the appropriate
place so applied by my update scripts automatically when I git pull a new
kernel update. And I've a few longer term not bug-fixes but behavior-
change patches I auto-apply to updates of various packages in much the
same way.) And even when that doesn't work, most of the time I can still
work around the problem with hacks like that menu thing, as I did on MS,
but now on Linux it's a last resort, not the first-resort workaround,
because on MS I lacked the source to do anything else.
> Even early Linux
> installations apparently only crashed for one reason: Me doing something
> stupid. I learnt a load about the system, learnt to write shell and perl
> scripts and used Linux for everything at some point. Yes I did have
> Windows 95/98 and Windows NT 4.0 dual boots on my device back then, also
> because I needed to look into both and understand how they work in some
> ways but at some point, I just removed them and didn't feel like
> something was missing.
At the 3-month point I was already seldom booting to the MS side, and
when I did, I'd do what I booted to it for, and then sit there wondering
what there was to actually /do/ on MS, much as had been the case on Linux
in my pre-switch experiments with it. By six months in I had pretty much
cleared out all the "extras" on the MS side and was down to the bare
installation (plus a few power tools I considered mandatory), so as to
shrink its partition and make more room for Linux. By 9 months or a year
in, I decided there was no point keeping the actual installation around
any longer, as I never used it, so I got rid of it, only keeping the
reinstallation cab files around, just in case. Some time after that, I
had a disk go out, and I eliminated everything MS in ordered to make more
room on the older/smaller disk that had been MS, so I could expand my
backup on it into a working Linux installation.
I never missed what I was removing in any of those steps.
Before the switch I had actually researched wine as well, thinking I
might run a few MS apps in wine on Linux, but it turned out I never had
the need (tho I do occasionally still run one 1993-vintage DOS game,
Master of Orion, in DOSBOX, being 1993 era, it's only a few megs of
storage, and a few hundred K of memory in dosbox, and that's the only
proprietaryware I kept, and still keep around), as the freedomware
alternatives were fine, for me.
> Yet, there are and were things I didn't manage to completely understand.
> Window managers were one of them
I managed to miss the pure WM thing, and always had enough room and
memory to run the kde desktop, which as I said I standardized on
relatively quickly, within the first three months.
>> 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.
> I have apparently installed this and played around with it for a while,
> but it doesn't work well for me, mostly for two reasons: Indeed it is
> way too clumsy on a "larger" screen and I didn't manage to tweak it in
> example by making fonts and icons smaller. And it doesn't seem to behave
> similar to plasma-search in allowing to switch to already open/running
> applications. It seems an interesting approach, but it's not for me.
Thanks. I had wondered what you'd think about it, but it seems not being
the default it hasn't gotten that much attention or development beyond
the basic concept, so I can see how you'd find it a poor alternative to
the more fully developed gnome dash, and why you'd thus prefer something
[65-inch 4K main monitor]
> Wow I *can* imagine this is more than enough space to work with.
> Actually, my setup is *way* more limited. In the office I'm using a
> dual-monitor setup running a what I think is 24" monitor at 1920x1080 as
> primary display and the laptop internal display (1600x900) as secondary,
> at times. On the road and at home, I only use the laptop display. Given
> that, I mostly use windows in full-screen and have multiple windows on
> the same workspace just in a very few situations (like merging code in
> editors or comparing different configuration files on different hosts
> using different remote screen sessions). This setup is somewhat small
> but for most of my situations it works well as, having been working with
> laptops for quite a while now, most of my workflows are accustomed to
> having "small" screens. Still however I guess I will upgrade my hardware
> at least in next year, the laptop display could be better in many
> respects. :)
Other than my primary desktop/workstation, which I've continuously
upgraded both hardware and software on from a 486sx25 with 4 MB RAM and a
130 MB hard drive back in the early 90s, so it never really became a
different computer all at once, I did have a generation 1.5 netbook, and
Acer Aspire One, with the original 32-bit Atom CPU and a 9-inch 1024x800
(IIRC) resolution screen, at one point.
It's long gone now, but I had a 32-bit-chroot build image for it on my
main machine, and had KDE 4 installed on it.
So I know all about running apps full-screen, stacked-windows, as that's
what I did on it.
Your 24" external is similar to what I upgraded to the big-screen TVs as
monitors from, but the internal is probably a bit bigger than my 9"
netbook internal was, probably at least 11" and likely 13 or 15".
... I still think about getting a 64-bit replacement for that netbook,
which I really liked. The biggest problem with it was updates, which
because it was 32-bit only while my main machine was 64-bit, had to be
built separately. As a consequence, because I didn't use it as much as
the main machine, it'd go some time, a year, once near two years, between
updates, which made them quite painful, tho the pain was reduced somewhat
by having already done the update on the main machine.
So I'd definitely need 64-bit and would want the same general
architecture (both amd of similar ages and CPU features, for instance) as
the main machine, so I could build updates once for both machines. And
I'd probably want a /somewhat/ bigger screen, but still a reasonably
small machine, so say 11 or 13 inch.
I've thought of doing it as a tablet, or convertable, too, but it'd still
need to be amd64, not arm or something. I've looked at chromebooks with
the idea of sticking a proper Linux on them, as that's the right price-
point and hardware as long as it's amd64, but that requires additional
research to be sure it's suitably compatible with a gnu/linux reimage,
proper mainline drivers not chromebook driver blobs, etc. (I'm not even
considering a reimage from MS if I buy it new, tho I might if I go used.
My $$ aren't going toward the MS statistic, even if I'm reimaging to
Mainly I just haven't gotten around to doing the research and getting
it. But it's on the list...
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