Bon, je viens de jeter un oeil à la dernière version (celle fournie avec KDE 4.2). Effectivement, c'est déjà beaucoup plus sexy, même si ça n'était pas vraiment un point bloquant pour moi.
On peut effectivement demander à rendre le HTML d'un mail, mais il ne semble pas vouloir le faire par défaut (il y a un paramétrage, quelque-part, peut-être?)
Parmi le merdier sans nom qu'est ma boîte mail, j'ai observé les différents comportements suivants :
* pour des mails en pur HTML (sans alternative texte), j'ai un bandeau à gauche indiquant que le message est en HTML (pas génant, c'est assez discret). La zone d'affichage du mail montre la source brute, avec un encart liseré de rouge proposant de "rendre" le source en question. C'est effectivement plus fiable que de charger sans précautions, mais à choisir ça serait pas plus mal de charger le mail sans images, références externes ou scripts. En tous cas et en l'état, ça a de quoi paniquer plus d'un décideur.
* pour des mails en texte brut, c'est bien évidemment tout bien comme il faut (c'est pas nouveau). Un bandeau à gauche indique la nature "non-HTML" du message, et le texte est proprement rendu, les liens detectés sont rendus cliquables automatiquement. Bref, nickel pour qui n'utilise que du texte brut.
* pour _certains_ mails en multipart, il choisit (arbitrairement?) de ne considérer que la partie "texte brut". Le mail apparaît donc exactement comment un mail en texte brut (à l'exception de l'arborescence de la structure du mail qui révèle l'existence d'une "part" en HTML).
* pour certains _autres_ mails en multipart (apparemment, ceux-là viennent de Thunderbird), il fait une joyeuse synthèse, signalant le mail comme étant HTML mais affichant d'abord l'alternative texte, puis (en ligne) le source HTML muni de son encart liseré de rouge. Si l'on demande l'affichage du HTML, on se retrouve donc avec (plus ou moins) deux fois le même message affiché à la suite.
* un mail composé en HTML dans KMail directement dans la catégorie "je zappe le HTML sans autre force de procès" à la lecture.
Enfin, ma structure a jugé bon (il y a longtemps) d'utiliser les signatures "graphiques" de Thunderbird. On aime ou on n'aime pas, mais force est de reconnaître que c'est assez répandu (et pas que chez les utilisateurs de TB). Celles-ci ne passent pas _du_tout_ sous KMail (on peut toujours afficher la pièce jointe correspondant à l'image, mais jamais elle n'est affichée "en ligne"). Ceci étant dit, les signatures graphiques sont une habitude dont - à titre personnel - je ne rafole pas et je serais très heureux d'avoir une bonne raison de pouvoir les mettre au rebut. Une signature texte bien faite me semblant mille fois plus efficace (surtout avec certains webmails "connus" qui ne gèrent pas ou mal les images "en ligne").
Au final, ça m'a fait du bien de re-voir Kontact après quelques années. Beaucoup de choses semblent bouger, et c'est bien. Mais, alors que je fondait beaucoup d'espoir sur son utilisation professionnelle il y a quelques années (notamment via la possibilité de "simuler" du groupware avec un simple serveur IMAP), force est de reconnaître que ça n'est toujours pas ça. Des projets comme Akonadi poussent (ou tirent?) dans le bon sens, mais à l'heure actuelle je ne vois pas une boîte qui troquerait son baril d'Exchange contre deux barils de KMail. Même au prix imbattable de ce dernier.
[^] # Re: Et?
Posté par Larry Cow . En réponse au journal Vista, moins pire qu'on le dit. Évalué à 2.
On peut effectivement demander à rendre le HTML d'un mail, mais il ne semble pas vouloir le faire par défaut (il y a un paramétrage, quelque-part, peut-être?)
Parmi le merdier sans nom qu'est ma boîte mail, j'ai observé les différents comportements suivants :
* pour des mails en pur HTML (sans alternative texte), j'ai un bandeau à gauche indiquant que le message est en HTML (pas génant, c'est assez discret). La zone d'affichage du mail montre la source brute, avec un encart liseré de rouge proposant de "rendre" le source en question. C'est effectivement plus fiable que de charger sans précautions, mais à choisir ça serait pas plus mal de charger le mail sans images, références externes ou scripts. En tous cas et en l'état, ça a de quoi paniquer plus d'un décideur.
* pour des mails en texte brut, c'est bien évidemment tout bien comme il faut (c'est pas nouveau). Un bandeau à gauche indique la nature "non-HTML" du message, et le texte est proprement rendu, les liens detectés sont rendus cliquables automatiquement. Bref, nickel pour qui n'utilise que du texte brut.
* pour _certains_ mails en multipart, il choisit (arbitrairement?) de ne considérer que la partie "texte brut". Le mail apparaît donc exactement comment un mail en texte brut (à l'exception de l'arborescence de la structure du mail qui révèle l'existence d'une "part" en HTML).
* pour certains _autres_ mails en multipart (apparemment, ceux-là viennent de Thunderbird), il fait une joyeuse synthèse, signalant le mail comme étant HTML mais affichant d'abord l'alternative texte, puis (en ligne) le source HTML muni de son encart liseré de rouge. Si l'on demande l'affichage du HTML, on se retrouve donc avec (plus ou moins) deux fois le même message affiché à la suite.
* un mail composé en HTML dans KMail directement dans la catégorie "je zappe le HTML sans autre force de procès" à la lecture.
Enfin, ma structure a jugé bon (il y a longtemps) d'utiliser les signatures "graphiques" de Thunderbird. On aime ou on n'aime pas, mais force est de reconnaître que c'est assez répandu (et pas que chez les utilisateurs de TB). Celles-ci ne passent pas _du_tout_ sous KMail (on peut toujours afficher la pièce jointe correspondant à l'image, mais jamais elle n'est affichée "en ligne"). Ceci étant dit, les signatures graphiques sont une habitude dont - à titre personnel - je ne rafole pas et je serais très heureux d'avoir une bonne raison de pouvoir les mettre au rebut. Une signature texte bien faite me semblant mille fois plus efficace (surtout avec certains webmails "connus" qui ne gèrent pas ou mal les images "en ligne").
Au final, ça m'a fait du bien de re-voir Kontact après quelques années. Beaucoup de choses semblent bouger, et c'est bien. Mais, alors que je fondait beaucoup d'espoir sur son utilisation professionnelle il y a quelques années (notamment via la possibilité de "simuler" du groupware avec un simple serveur IMAP), force est de reconnaître que ça n'est toujours pas ça. Des projets comme Akonadi poussent (ou tirent?) dans le bon sens, mais à l'heure actuelle je ne vois pas une boîte qui troquerait son baril d'Exchange contre deux barils de KMail. Même au prix imbattable de ce dernier.