Steven D'Aprano posted on Tue, 11 Sep 2012 11:38:58 +1000 as excerpted: > On Tue, Sep 11, 2012 at 12:21:40AM +0000, Duncan wrote: > >> However, there HAS been discussion of the possibility of implementing a >> simple "dumb tag stripper" mode (which will actually need to be >> reasonably smart
> +1000 on this idea. > mutt does something very similar for email. It can be configured to use > a console browser like links, lynx or w3m to dump the html to text, then > display that. > > http://jasonwryan.com/blog/2012/05/12/mutt/ > > I see no reason why Pan couldn't use an external dependancy for this > like mutt does. As you suggest, stripping tags is hard, there's no > reason why Pan should be forced to implement its own when it can push > the hard part onto existing tools, of which there are already at least > three. That's a very useful suggestion. =:^) The apps tab in pan prefs could have another entry, "HTML text dumper" or some such. If the pref is left blank (the easy default), pan falls back do doing what it does now. If a command is configured, pan checks to see if points to an executable, and if so, it dumps html parts to it and posts the resulting STDOUT. A combobox dropdown could have preset entries for the three text-browsers you mentioned, with a "custom" entry like the other apps configs offer, where a user could type in their own. >> Personally, I was rather negative on this whole idea, until I saw how >> effectively claws-mail implemented it (after having little choice but >> to switch to /something/ other than the kmail I'd been using for nearly >> a decade, when they akonadified and broke everything, > > Check out Trinity, a.k.a. TDE, a.k.a. "KDE 3, back when it was good, > reborn ascendant!!!". I haven't installed it myself (yet), but I'm > impressed by the health of the small but dedicated community grown up > around it. Naturally the KDE 4 people hate it with a passion. I admire them and what they're doing, and certainly would have stuck with kde3/trinity at least for a year or two had the option been around back in the kde 4.2 and 4.3 era when kde was SO insistent that the still VERY broken kde4 was "ready for ordinary users". But, not having the option available back then, I sweated thru the transition, using a transition method that switched a single app at a time from the kde3 to kde4 version as I started with a kde3 base desktop enviornment and ended with a kde4 base desktop environment, configuring each app as I switched, finding replacement apps where the kde4 versions were simply still too broken, scripting my own solution for the missing multi-key hotkeys functionality, etc. I went thru all that rather than switching to a different desktop, because all along I figured kde4 would "get there" /eventually/, and because there really wasn't a good replacement. Yes, "release early release often" as is so often said about FLOSS, but it's far better to have everybody using what's still a 0.x (heh, pan, anyone?) or officially beta/pre-release version because it's already stable, as actually declared in practice by their users, than to do as kde4 did, having the devs insist it's release quality while the users continue to flee the brokenness in droves! Of course compounding the problem of CLAIMING it was ready when it WAS NOT, kde devs ALSO dropped support for the still very workable kde3, insisting people switch to the still incredibly broken kde4 for support, declaring it ready out of one side of their mouths while at the very same time stating on all sorts of bugs "oh, that feature isn't ported to kde4 yet." WTF? All this after a VERY high profile promise to continue support for kde3 "as long as there are users." So much for THAT! But I was right. 4.5 (4.5.4 or 4.5.5) was IMO what SHOULD have been released as 4.0. Each version thru late 4.5 increased quality and reduced brokenness. While the kde folks claimed 4.2 was ready for use, by the normal measure of big features still missing, not implemented at all, it was still alpha. 4.3 reached beta, most features sort of there but unstable, often not working, and quite rough where they WERE working. 4.4 finally reached release candidate status, all or nearly all features working and mostly stable, but still needing a bit of polish and various generally less critical bugfixes. Early 4.5 was the same way; in particular there were some serious graphics regressions, but by late 4.5, as I said 4.5.4+, those were fixed and kde4 was FINALLY at what SHOULD have been 4.0. Early 4.6 had some bad regressions again, in part because big parts of kde were switching from svn to git at the time and there simply wasn't the best cooperation and communication between the release team and all the various subprojects, so some got pulled from stale repos, some from half- switched repos, etc. But for the most part, the big exception being kdepim, late 4.6 was pretty good again, matching 4.5. And 4.6 was the first u* (udev/upower/udisks) as opposed to hal-based hardware helper version as well, so late 4.6 was pretty critical. Other than kdepim, 4.7 and on have in general been reasonably stable and on a less dramatic but continuing improvement trend, at least from here. Basically what one would expect from a mature and stable desktop solution. Meanwhile, the story of kdepim replayed the story of kde4 in miniature, only about six minor releases behind kde in general. This it was 4.6 when the proverbial fecal material hit the spinning air moving device. There were actually some minor hickups with kdepim 4.3 and 4.4 as the address book was akonadified. They actually skipped 4.5, working on the new akonadified kmail2. They released a kdepim 4.6.0 and 4.6.1 during the kde 4.6 timeframe, but these weren't synced with the rest of the kde release cycle. And in a replay of the kde 4.0 mess, it was only LATER that many users found out that the kdepim 4.6 releases weren't considered ready for ordinary use, they were intended as pre-release betas. kdepim 4.7's release cycle synced again with the rest of kde, but it paralleled kde 4.1 in that the devs still weren't calling it fully ready. kdepim 4.8 similarly paralleled kde 4.2 in that upstream kdepim dropped support for the earlier kdepim 4.4 and declared the now akonadified kmail2 in 4.8 ready for ordinary users. Unfortunately, JUST like the larger kde 4.2, it was still unstable and NOT ready for ordinary use, as it was still eating people's mail at times, and was otherwise misbehaving. Following the pattern, by 4.5 plus six releases... kmail2 as in kdepim 4.11 or so should FINALLY be reasonably stable and "ready for ordinary use". But I won't be personally finding out. Here, while I was skeptical of the whole akonadi thing, I thought I'd be fair and give them a chance. I tried the kdepim 4.6.0 and 4.6.1 versions, not knowing that 4.6.0 still wasn't considered ready for normal use (after all, they'd skipped the entire 4.5 cycle, and didn't release with the rest of kde 4.6 either, saying they were being extra careful to get things right...). But UNLIKE the general kde4 case, I had reasonable alternatives for mail, and ultimately chose one of them. A few days into kdepim 4.6.1, after having yet another email message disappear on me, after yet another restore a folder from backup because the entire FOLDER had gone missing, I realized there WERE other options out there, and decided enough was enough! By 4.7.0 I had switched to claws-mail for mail, altho I was still using kdepim's akregator for as my feed reader, and while it didn't directly use akonadi YET (the plans are that it will), akregator depended on kdepim libs that in turn pulled in akonadi, so I couldn't get rid of it for kde 4.7.0, but I was on my way! About half way between 4.7.0 and 4.7.1 monthly releases, so about two weeks into 4.7.0), I had settled on claws-mail for feeds as well, and critically, had figured out the necessary config and script magic to run two separate claws-mail sessions, one for mail and one for feeds, since I wanted to keep them separate. By two weeks into 4.7.0 I had that figured out, setup, tested, and my new feeds instance of claws-mail up and running, after which point I was FINALLY able to rid myself ENTIRELY of kdepim and with it, akonadi. The final removal of akonadi provided another bonus as well. I run gentoo, and of course gentoo allows configuring a lot of dependencies in or out at build-time, via USE flags, a feature that binary distros can't match because the choice has to be made at build-time, and if the support is there, libraries are linked in that must be there at runtime as well, regardless of whether the user actually uses their functionality or not. And, with the removal of akonadi, I was finally able to turn off USE=semantic-desktop for all of kde! That was a BIG (actually, I'd characterize it as more than big, HUGE, here! I seriously felt like I was an MS user who'd just found out what all that malware had been doing to his system speed, it was THAT dramatic, despite the fact that I had as much of it turned off as possible, previously!) improvement. Based on my experience, I'd say that a good portion of people's remaining complaints about kde4's being slow and bloated compared to kde3 are a direct result of all that semantic- desktop junk that wasn't there in kde3! Unfortunately, most distros are binary distros and their users don't really get a chance to see what a kde built without all that semantic- desktop crap actually performs like! There's certainly a niche for a kde- based binary distro that turns it off, using non-kde alternatives like claws-mail, where the no-semantic-desktop choice forces it. But to my knowledge, there's no binary distro filling that niche yet. Oh well... Bringing things full circle, that rather big detour is all in support of my point, in reply to your trinity suggestion above. I really *DO* respect those guys for doing that. And it's certainly a solution I'd recommend to anyone who was on a long stale Debian stable or something and is only now having to try to deal with kde4, or for those who are still having serious problems with it. Unfortunately, in practice the solution came along too late for many, and they've moved on to other things now, or finally found a kde4 solution that actually works for them, as I have. There's yet another alternative out there as well, for those who like many of the kde4 apps, but who still struggle with plasma, likely because their hardware is simply too old to deal with plasma's admittedly stronger demands on graphics and memory as well as CPU. (Plasma's actually remarkably flexible and can be configured to work much like kde3's kdesktop and kicker solution, if it's simply a UI familiarity problem, but that doesn't help if the hardware's simply not upto it.) Again, I *REALLY* wish this thing had been available back in the kde 4.2 era, as plasma was one of the biggest problems at that point; most of the other apps were more straightforward ports from their kde3 versions and this were reasonably mature, while plasma was still new and definitely NOT mature. But unfortunately, the solutions didn't evolve until later, I think because at first nobody could quite believe kde was ACTUALLY doing what it did, dumping users into an immature and still very broken solution while pulling the support rug out from under the mature and stable previous version. Oh, well... (In that regard the gnome folks have it a bit easier, as with kde going before them, when gnome3 jumped the shark, people recognized it faster, resulting in the gnome3 cinnamon and mate alternatives appearing far faster than their kde4 alternatives parallels.) What am I talking about? The qt4-based Razor (razor-qt) desktop. Like you with trinity, I've not actually used it myself, but I've read some very good reviews, and I've already recommended it on the kde lists to someone who was in just the position I described above, he liked many kde4 apps, but plasma is still very broken for him, probably because his graphics and machine in general simply can't handle it. He said he'd look into it as it looked like it could be good, and I asked him to report his results, but that was only a few days ago and he's probably still working on it, so no results yet. While razor is its own far lighter desktop, from the reviews, it looks like it was deliberately designed with replacing kde4's plasma in an otherwise kde4 environment in mind, as well. So I'm guessing it should work in both modes, tho the review was actually of razor as an independent desktop. Here's the google search, with links to the homepage, the wikipedia entry, the arch-linux wiki entry, and various reviews, all in one place. =:^) http://www.google.com/search?q=razorqt Meanwhile, now that I have kde4 stripped of akonadi, nepomuk, etc, and have otherwise configured it to work my way instead of it forcing me to work its way, including switching several of my previously kde solutions (konqueror, kmail, akregator, k3b, kaffeine, amarok...) to gtk-based or other alternatives (firefox, claws-mail, claws-mail, graveman, smplayer/ vlc, mpd and various front-ends which TOGETHER are still less bloated than amorok and its dependencies, respectively), I'm actually not only / as/ happy with kde4 now as I was with kde3, I'm actually HAPPIER with it! =:^) One more thing. Sometime in the kde 3.5 era, I was thinking about trying to dump gtk entirely. After all, on gentoo everything's built from source so every installed package has a higher cost of maintenance than on a binary distro, greatly helping to encourage the recommended security practice of only having installed only what you actually use. At the time I only had two big gtk-based apps installed, firefox and pan, and firefox was my second browser, with konqueror my primary, so really, all I needed to do was find a good replacement for pan, and I could probably dumped gtk entirely. *MY* how things change! Ironically, all those replacements listed above, save for smplayer and vlc for kaffeine (both of which have a qt4 based interface), and mpd with its front-ends of which there's a whole list, I use qt4 front-ends because I still use kde but there's gtk alternatives I'd be as happy with, are gtk-based. So while I actually like the kde4 desktop and base, now that I've gotten rid of semantic-desktop and some of the apps, I'm actually running much more gtk now, and should kde ever try that trick again, I probably WOULD simply dump it this time, maybe for xfce. But the kde-frameworks aka kde5 upgrade's going to be vastly different than the kde4 upgrade, FAR less disruptive and rather more incremental change than paradigm-shift kde4 was in many ways, so more like the kde2 -> kde3 upgrade (which I switched to Linux just in time to catch) than the kde3 -> kde4 upgrade. And that'll be happening about the same time as the whole xorg -> wayland shift as well, its own paradigm-shift with effects on my desktop and what runs on it that I really can't predict at this point. So while I /can't/ predict that I'll still be on kde, probably kde5/frameworks, after the switch to wayland, I'm actually both in a better position now to change if I need to, and reasonably confident that never-the-less, I'll still be on kde for kde5/frameworks and wayland, but /without/ the struggle that came with the kde3 -> kde4 upgrade. One can hope anyway, but I believe I'm "hoping" from a far stronger position this time, so I'm actually reasonably confident that I'll be happy with /how/ it goes, regardless of /where/ it goes. =:^) -- 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
