plasma search in application launcher?

Duncan 1i5t5.duncan at
Thu Sep 27 13:12:54 BST 2018

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'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, 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, 
after that!

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 
than gtk-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 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
> look).

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

More information about the kde mailing list