--===============0371790999==
Content-type: multipart/signed; boundary=nextPart1813866.JBnbXH4x9U;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

--nextPart1813866.JBnbXH4x9U
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Monday 09 August 2010, Richard Creighton wrote:
> On Sunday 08 August 2010 18:29:49 you wrote:
> > Am Sonntag, 8. August 2010
>=20
> 19:56:30 schrieb Richard Creighton:
> > > I normally have the 'inbox' set to
>=20
> text only.   Certain trusted
>=20
> > > correspondants have a filter set to move
>=20
> the message to another folder
>=20
> > > which allows the display of HTML.   You
>=20
> could set up the same type of
>=20
> > > defaults for the ability to reply in HTML
>=20
> without forcing anyone to
>=20
> > > violate their rights/desires to never do so.
> >=20
> > Hi Richard,
> >=20
> > would you mind sharing how you set up no HTML as
>=20
> default, but having it
>=20
> > allowed for certain contacts. Is there a good
>=20
> tutorial for that online?
>=20
> > Sounds interesting to me.
> >=20
> > Thanks a lot,
> >=20
> >=20
> > Pascal
>=20
> Hi,
>=20
> Well, what I've done is go into SETTINGS for KMail and
> select SECURITY -> Receiving and ensure the checkboxes for PREFER
> HTML and the one under it are both OFF.
>=20
> Then, save and exit the settings
> configuration.   Then select a folder and from the menu at the top of
> the window, select "Folder".  There you can turn on the 'Prefer
> HTML' checkbox which will affect only the selected folder.   You can
> do this for as many folders as you see fit.   Remember, the default
> is now OFF so any you want ON have to be specified individually by
> folder.   This is only for automatic DISPLAY of HTML but it does
> enable you to avoid all the "warnings" regarding HTML display.   It
> doesn't solve the issue of replying in HTML, but under settings for
> KMail, there is a provision for external editor.   This "sorta"
> works but it is selected all the time, even if you don't want HTML
> or other special editing capabilities.   Thus, it is not a good
> substitute for an integrated HTML editor that is controllable by
> KMail settings.
>=20
> I am not
> aware of any good tutorials on this.   The *manual* for KMail kinda
> glosses over this subject...probably for the same reason as the
> inability to reply in HTML if you choose to do so for whatever
> reason...eg, the dev has no real interest in interfacing to external
> editors, which is their prerogative but it is my opinion that just
> like going to the bathroom....the jobs not done till the paperwork
> is done.   Paperwork in the programming world includes documentation
> IMO.  Not as fun as coding perhaps, but at least as important.

True. But who says that the developers have to write the documentation.=20
Non-developers cannot contribute code to KMail, but most of them should=20
be able to contribute documentation. I should also point out that=20
developers are largely unable to write user-readable documentation=20
because they often use too much technical jargon.

If you are interested then have a look at
http://techbase.kde.org/Projects/Documentation/KDE4/kdepim/kmail


Regards,
Ingo

--nextPart1813866.JBnbXH4x9U
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkxgSrMACgkQGnR+RTDgudhh+gCgwLI+A2XfVq3MQKdtvBcBObKL
BI4An3ZW0J2WxmZXJgzi9FxiTSbedkTG
=F41t
-----END PGP SIGNATURE-----

--nextPart1813866.JBnbXH4x9U--

--===============0371790999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM users mailing list
kdepim-users@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users

--===============0371790999==--