Rui Maciel posted on Wed, 19 Oct 2011 00:53:56 +0100 as excerpted: > On 10/18/2011 09:00 AM, Duncan wrote: >> OK, I'm rereading this thread based on the current sqlite solution >> discussion, and... >> >> What do you think of the new, akonadified (and thus sqlite, mysql, or >> the experimental postgresql backends) kmail? > > Personally, I think it's horrible. After using kmail since the days of > Kubuntu 5.04, this akonadi cruft forced me to switch to Thunderbird, and > never look back. In fact, the only time I ever looked back was to > wonder if it would be that hard to fork kmail into a stand-alone email > client, but it appeared to be too much trouble for such a small reward.
FWIW, thunderbird's not my style. But claws-mail sure is! =:^) My reaction was along the lines of "too bad there's not a kde (or qt... maybe there is; I've not read of it) mail client that "just does mail right", like the gtk-based claws-mail seems to do; I don't care what / else/ it might do as long as it doesn't depend on the kitchen sink or take hundreds of megs of RAM to do it. But kmail is very much a part of kdepim, with dependencies to kdepimlibs and kdepim-common-libs as well as the general kdelibs, and it's kdepim- common-libs that pulls in akonadi. It'd be possible to fork it, but not easy, as one would have to effectively fork kdepim-common-libs and kdepimlibs from kde 4.3 era to avoid the akonadi dependencies that started with kdepim 4.4, pull out all the code that wasn't needed for kmail, and probably bundle the rest, either static-linking or changing the library and symbol names so they didn't conflict with the akonadified kdepim if parts of it were installed as well. It's probably easier to start (nearly?) from scratch, depending on qt and possibly kdelibs (based on whether you want a kde-independent qt-based app or full kde), and possibly pulling in non-kde mail-handling libs, but preferably nothing from kdepim at all. > Now, after installing Kubuntu 11.10, this akonadi/nepomuk crap is > becoming so inconveinent that I'm currently considering dumping Kubuntu > entirely and adopt some other distribution/DE package. I simply don't > know why KDE people insist in pushing that stuff, but at least they are > succeeding in driving people away from their DE, which is a shame. FWIW, while kde does still make the semantic desktop stuff optional in general (tho it's required for certain apps, including pretty much anything kdepim, since kdepim-common-libs pulls in akonadi, the reason I had to dump akregator too since it's kdepim based), the options must be chosen at pre-compile configure time. That means that binary distributions will have to choose whether to activate it or deactivate it by policy, and /most/ binary distributions generally activate most option features, unless it's a specific feature of their distro that they don't. (One major exception to this is that distros that default to a particular desktop environment will often not activate the options for others, since that often pulls them in. Thus, gnome-standard distros will deactivate the optional kde support features in many apps, and naturally, kde-defaulting distros would do the reverse, in ordered to avoid pulling in both desktops. Same for xfce, etc, for distros/spins/whatever that default to them.) As a result, among binary-based distros, you'll likely either need to choose a distro defaulting to something else (gnome/unity/xfce/whatever) and then by policy deactivating the semantic-desktop stuff in kde in ordered to reduce dependencies for a non-primary desktop, or find a kde- focused distro that has as a primary feature that they disable the sementic desktop stuff. Or go source-based. I'm not sure how arch-linux handles this, but I *DO* know (since I'm running it that way) that gentoo specifically exposes the semantic-desktop USE flag for kde, letting the individual user/sysadmin decide. But even gentoo's handling isn't perfect. Without getting too technically specific, while it makes sense that if one wanted the semantic-desktop features for say, dolphin, that kdelibs would need compiled with it as well. No argument there. But, the reverse need not be the case; just because one runs a single app that requires semantic-desktop (here, after dropping kmail, it was akregator, since while it didn't actually use akonadi, it required kdepim- common-libs, which required akonadi, and akonadi requires semantic- desktop), while that might indeed require kdelibs be build with semantic- desktop as well, that should NOT require that dolphin be built with it too! But gentoo/kde used semantic-desktop= dependencies where they should have used semantic-desktop? dependencies, forcing the dependencies both directions instead of just one, which meant that because akregator in a round-about way required akonadi which required semantic-desktop, which then legitimately required it for kdelibs as well, that required ALL packages with the semantic desktop option be built with it on. Thus, even with kmail gone, as long as I was still using akregator, that forced me to keep semantic-desktop on for all the rest of kde I had installed as well. Which once I realized it, forced my hand as I was tired of semantic- desktop by then and wanted off, so I had to find a replacement for akregator as well even tho had gentoo/kde had the right dependencies, I could have probably simply turned it off for all the other apps (dolphin, etc) while leaving it on for kdelibs, etc. As it happened that turned out for the better since I ended up figuring out how to run a second claws-mail instance, not for mail, but as my feed- reader, and I'm happier with it than I was with akregator, now that I've actually switched. But the hassle cost of switching was high enough that I would have certainly waited somewhat longer, and might have never actually switched, had my hand not been forced. Meanwhile, however, even tho I had both strigi and nepomuk turned off and was no longer running akonadi, the system didn't get a lot of performance back until I actually turned off USE=semantic-desktop (plus a few related USE flags), uninstalled anything kdepim or akonadi related entirely, and rebuilt kdelibs, dolphin, etc, with USE=-semantic-desktop (the - turning it off). But when I actually did so, *WOW* *WHAT* *A* *DIFFERENCE!!** I swear, it was as if I was back on MS again and had just discovered how much of a drag the real-time anti-virus scanners were having on the system. It was as if my 4-core system suddenly got two extra cores, or increased in clock-speed by half a GHz or so! It was *SO* totally worth it it's not even funny! I'm now rather convinced that a good half the time (the rest could be graphics performance related or the like, I upgraded from an old Radeon 9200, r2xx series, to a new(er) Radeon hd4650, rv730, about kde 4.3 or 4.4 era, so I know about that one from personal experience as well) people complain about how bloated and slow kde4 is, as opposed to kde3, the real problem is the semantic desktop ****, even if they have the bits they can turn off (strigi file indexing, nepomuk, akonadi if they're not using any already akonadified kdepim apps) actually turned off. Seriously, pre-compile-configure-time-disabling semantic-desktop and related technologies (strigi, nepomuk, akonadi, soprano, redland, raptor, virtuoso) and eliminating them from my computer has upped my kde4 satisfaction levels from perhaps 80% of what they were with kde3, to 95%+. There's still a few niggles, but I can accept that by definition, the kde devs, not being me, will never match my feature decisions 100%. Meanwhile, if the fact that I decided if konqueror isn't good enough for most kde devs to consider as a serious browser[1] is thrown in as well, with my resulting switch to firefox, thus excluding konqueror from the evaluation, that personal kde4 satisfaction level rises to 98%+ of the comparable level for kde3. Obviously, turning off semantic-desktop made a BIG difference for me, and I can now EASILY envision sticking with "core kde" as my desktop for quite some years to come. Before I likely would have, but switching was possible. Now, unless kde pulls another kde4 on us and there's quite some indication that they've determined that the kde5 upgrade at least will be MUCH less disruptive, there's little chance I'll switch at all. That's an impressive improvement no matter how it's sliced! =:^) I actually find it interesting and rather ironic, that I've come by this MUCH higher satisfaction with the core-kde4 desktop environment only as I've dumped several formerly kde app choices in favor of alternatives, and hard-disabled at pre-compile-configure-time some of what has been marketed as some of kde4's biggest and best headline features, but that has certainly been the case. <shrug> ---- [1] The recent bugs in konqueror, allowed to persist for many feature- release versions despite the claim that kde was ready for ordinary use, demonstrates quite conclusively that few of them consider konqueror more than a toy. As an example, until 4.6 at least and arguably 4.7 (it was I believe there in 4.6 but rather obscure, it's part of the network category in kde settings, with 4.7), kde4 had no UI for manually reverting trust on security certificates should they be found to be compromised. Recent security certificate and even whole issuer compromises have surely proved the case, but even before that, no sane person with any knowledge of security certificate mechanisms at all could possibly find that a tolerable situation for a browser they depend on for Internet shopping and banking, or for webmail as a dissident in someplace like Iran. It therefore follows that no sane person at all concerned about konqueror security could have qualified kde versions between 4.2, when kde started making the claim, and 4.7, when the issue was fixed, as ready for ordinary users, without such a security certificate configuration UI in place or at least a caveat that said readiness doesn't yet apply to konqueror (or any other component using kde's common certificate handling structure). Since kde did announce kde 4.2 and later versions as ready for ordinary users without such a caveat, it therefore follows that the majority of kde devs cannot possibly consider konqueror anything more than a toy, and don't use it as their browser, at least for anything "serious" like supposedly secure net shopping or banking, or for use by those wishing their webmail access to be secure, etc. It's thus self-evident that the majority of them use something else as their default browser, and consider konqueror only a toy not worth worrying about the security status (or for that matter, bug-free functionality in other areas) thereof. Once I realized that, I realized that I could no longer trust konqueror under those circumstances either, and I best find a more satisfactory default browser for myself, as well. It took some configuring as I had a lot of klipper actions, etc, hard-coded to konqueror, and I had to setup passwords all over again in my new browser, since kwallet is a kde- specific technology, but I've had firefox setup as my default browser for about six months now (it's 4.7.2 now and it was 4.6.2 then, IIRC), and most of the formerly hard-coded-to-konqueror configs now use xdg-open, thus opening with the configured default browser regardless of what it is. -- 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
