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 many.) > 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 alternatives. 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: > > https://dm.zimmer428.net/2013/04/kde-kubuntu-and-a-bit-of-rant/ 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 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 well. 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 work. > 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 different. [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 Linux.) 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