Re: [Pan-users] html

[Duncan]

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