Chuck Burns posted on Tue, 29 Nov 2011 18:39:47 -0600 as excerpted:
> I have used claws in the past.. but I found it's UI to be.. lacking.
FWIW, I first tried it a /long/ time ago, IIRC early 2002 when it was
still the testing version of sylpheed, before I settled on kmail for nine
years. I find it somewhat ironic that I rejected it then, but am back on
it all these years later, and find myself wondering at what point it
would have become better for me than kmail, had I known about it at the
time.
As for the claws-mail gui, it might be slightly less fancy than current
kmail, but it MORE than makes up for it in configurability.
The configurability of its hotkeys puts pretty much every kde app I've
ever tried (but for the old kde kaffeine, perhaps, tho I'm now using the
qt4 based smplayer with similar configurability) to shame, and that's
saying something! Literally /every/ /single/ /function/ it's possible to
invoke via menu or other action, has a configurable hotkey, and for the
extensions I've used, that extends to them as well. Actually configuring
some of them might require editing its gtk2 style entirely unordered
keydump file, but I copied that off somewhere, ordered it into GUI menu
order, and made my changes. That's actually how I know how much
functionality has available configurable hotkeys, because I reordered the
keydump file and saw them all! I actually discovered some functionality
I had no idea was there that way, as well.
The color scheme, etc, fits in quite well with kde, if one has the
appropriate option checked in kde's color config, to export it to non-kde
apps. That's a BIG thing for me too, as I *STRONGLY* prefer a so-called
'reverse" color scheme, with light text on a dark background, to the
extent that the default greyish color schemes of both kde and gtk make me
mildly physically nauseous, both for the colors and because of all that
light background. So it was definitely a MUST that any mail client I was
to use either had to have a decidedly non-traditional colorscheme that I
could be comfortable with, or more likely was compatible with kde's
colorscheme export to non-kde apps option, and claws, being gtk-based,
definitely fit that requirement.
And just as with the mh text-based mail client it inherited its mailstore
format from, claws is /extremely/ extensible with external commands and
scripts, since an individual message is simply a file in what amounts to
raw rfc standard message format. Maildir actually inherited that quality
from mh format, its predecessor, and for both of them it's billed as a
major feature advantage compared to monolithic file-per-folder formats
such as mbox. For whatever reason, however, mh and the family of mail
clients based on that format (including both sylpheed and claws) seem to
put far more emphasis on external script extensibility than do the maildir
clients I've come across, and it's not unusual at all for longtime users
of mh-format clients to have developed a number of their own scripts that
they use for customized further processing. See here for LWN's Jon
Corbet's article on the subject:
http://lwn.net/Articles/89403/
Choice quote:
"""""
It should be possible to do anything with email - even things that the
developer of the mail client might not have thought of. It must be
possible to make connections between the mail client and the LWN site
code. It should be possible to manipulate messages and folders with shell
scripts and programs without great pain. The client should be a powerful
tool for working with electronic mail, but it should be just the
beginning point, rather than the final destination.
"""""
So while the UI might be a bit... lacking... as you put it, that's "just
the beginning point", as Jon Corbet put it. Many mh-format mail clients
and their users do all sorts of scripting, etc, with the mail data, and
claws-mail is designed with just that sort of extensible scripting in
mind, with a number of configurable ways to invoke external commands via
the GUI, either setting them up to be run routinely, say when entering a
particular folder or on any mail it receives, or invoked interactively.
Again, if it's a function configurable or invokable from the claws GUI,
it's got an assignable hotkey, and invoking an external command is as
simple as invoking that hotkey. =:^)
Wow, I guess I'm quite the claws evangelist, aren't I? But the bottom
line is, the more I work with claws-mail and the more I understand its
incredible configurability and extensibility, the more I like it!
I originally chose KDE over Gnome when I was first coming over from MS,
because, ultimately, I couldn't understand how a FLOSS desktop could only
allow theme changes, not have a colors selection control panel for
changing individual colors, as even the proprietary MS had! Well, that
was the ultimate symptom that made my choice, anyway, but it reflected
the fact that even back with gnome 1 and kde 2, kde's idea was provide
and expose the tools for the user to choose their own config, while
gnome's was the user's too dumb to be trusted with powerful configuration
tools and is only confused by them. That's one of the big reasons I
still use kde today, and why I stuck with kde4 despite all the abuse it
was heaping on the users when they kept saying it was broken in the early
days, kde has always emphasized user configurability and customization.
When I discovered gentoo, I found it pretty much the perfect fit, for
much the same reason, it's high configurability, while still automating
the process via tools designed for the purpose. (FWIW, I still don't
quite get why some gentoo folks like gnome, as it seems to me the
philosophies are entirely antithetical to each other, the distro that
exposes ultimate control to the user, the desktop that insists that its
way is best and any user who thinks otherwise is just to dumb to know
better, but oh, well, it seems there's quite a few gentoo gnome users out
there, despite my lack of comprehending why they'd even bother with gentoo
if they like gnome, or conversely, how they can /stand/ gnome, if they've
found the right distro in gentoo.)
Now, it seems I've found a similarly perfect fit with claws-mail. To me,
it's the perfect balance of exposed tools that allow the user to both
customize things exactly to the degree necessary or desired, and get on
with the program without getting in the user's way.
But just as there's a lot of people out there who prefer the gnome
desktop and a binary distro, there's a lot of people out there for whom
claws isn't going to be the right mail client as well. That's fine.
What's important for me, is that it works for me, and that it does better
than any other mail client I've found.
> I actually like the kmail interface.. but I see that it may be time to
> simply revert to the old kdepim4.4.x version.
That works, in general, for now. But be aware that there's going to be
more and more breakage going forward, as the rest of kde moves on. I
believe the upstream kde policy is that with 4.6, both were supported and
kdepim 4.6 was for early adopters, with 4.7, both are mostly supported
but the recommendation and clear focus is on kdepim 4.7, and with 4.8, no
further attempt at maintaining compatibility with the old 4.4 kdepim
series will be made... unless of course some new devs with that specific
interest appear and join kde with that specific goal in mind. Gentoo has
tried to keep kdepim 4.4 as a choice as long as possible, but there are
already bugs marked WONTFIX against kde 4.7, because that's upstreams
position as well.
So with 4.6 the old 4.4 kdepim should still work, with 4.7 it should, but
there will be and are specific bugs, and with 4.8, you'll begin having
serious headaches trying to manage it. Thus, unless you're a dev with
the time and energy to commit to it and want to take on the task,
preferably upstream, you better plan on ditching kdepim 4.4 by the time
you upgrade to 4.8, or you'll very likely be in for some very serious
headaches as a result. And by 4.9 it's likely to be unusable, if it's
even usable with 4.8.
Of course, if you're a dev with the skills and the time to devote to it,
I'm sure a LOT of users and some distros will be singing your praises,
much as many are the trinity project and its devs, at this point! =:^)
> I did, however, discover
> another qt4 imap client, but it appears to not be quite ready either:
> Trojita. http://trojita.flaska.net/ - I have gotten it to compile, but
> it apparently doesn't quite like my FreeBSD system, but I am trying to
> contact their support for it, as well.
Yes. I found trojita too, and looked at it. I was quite impressed, the
more so as a Gentoo user as it seems the author is as well, and if I had
been an IMAP user, despite its still somewhat rough status, I'd have very
likely tried it. But that would have meant doubling my trouble as I'd
have had to install and learn to configure and maintain an IMAP server as
well, and while I was still quite temped and might just have done so if
trojita had been a bit more mature, or if I hadn't discovered claws, I
/did/ discover claws, and it turned out that was definitely the right
solution for me.
The one thing I AM worried a bit about with claws, is the longer term
outlook as projects and distros gradually switch to gtk3. I have
absolutely /no/ idea what the claws-mail devs' thoughts are on that
conversion, and whether they'll do it (or indeed, whether it's already
done and just a config switch), or plan on sticking with gtk2 only for
the foreseeable future. At about 2-3 years out, I expect forward-leaning
distros such as gentoo to be preparing to discard gtk2 just as they did
gtk1 before it, and at that point, any users of apps that haven't
upgraded yet will be up a creek. I REALLY don't want to be going thru
this whole ordeal again in less than 6-7 years at the earliest, so not
knowing, I AM a bit concerned.
--
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
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
