From kde-pim Tue Nov 11 21:10:26 2008 From: Ingo =?iso-8859-1?q?Kl=F6cker?= Date: Tue, 11 Nov 2008 21:10:26 +0000 To: kde-pim Subject: Re: [Kde-pim] user css controlled mail appereance... reload. Message-Id: <200811112210.28246 () thufir ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kde-pim&m=122643794715022 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1385615003==" --===============1385615003== Content-type: multipart/signed; boundary=nextPart1513396.s64eTtKBoV; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit --nextPart1513396.s64eTtKBoV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 November 2008, klebezettel@gmx.net wrote: > On Sunday 09 November 2008 21:22:22 Thomas L=FCbking wrote: > > Hi, > > i brought up this suggestion around 1 1/2 years ago, then some > > nasty things happened and i withdraw and kept the patch just for > > myself since then. > > > > I however kept it rather simple to avoid running into failing svn > > merges, so it's made up quite close around my needs (i.e. reads and > > adds a css from a hardcoded path. i'd rather offer a combobox > > managing various styles. only changed libkdepim/csshelper.*) > > > > Attached is a Screenshot. (just "fancy" header + some css) > > > > So if you're still interested, i'd extend the patch (user > > interface; and i'd like to change the used html code a bit - imho > > we could include the header html (inside div.header) from an > > external file if present - allowing easy reordering of items - and > > implement the currrently available headers as hardcoded special > > case (and fallback) on the general approach. at least the table > > lable should be replaced) > > > > Regards, > > Thomas > > Hiya Thomas! > > First I had the same approach like you reading external html/css > code. If you want to use the html/css-approach you have to ask > yourself how you would handle mails that does not come with all the > header data we assume (since the template should handle all of them). > Of course, most mails haeve Subject/From/To/Date data (but not > all?!). Some have additional CC/BCC/Attachments data. Now, reading > one html/css template file is therefore too static. You would have to > split the actual template into several files. Or the (one) template > file would have some extra structure with markers that you would have > to parse...I think this is possible, although not that nice. > > So this was about HTML/CSS Templates. Using only CSS templates (the > HTML would be some divs/spans in the c++ code) has some limitations? > At least I wasn't successful in trying to change the order of the > header elements (say, first showing the from data, below it the > subject and then the to-part). Maybe that are just my css skills that > are limited ;) Well, actually I changed the order with css (using > float/width/margin elements), but all the distances where static and > led to problems (especially dealing with long lines that wrap "into" > the next line). But if you say it's possible to change the order of > the elements (for long lines/texts, for increased font size etc...) > just by using css, that would be just cool :) Hmm, but then again - > can we change everything just by css? What about some javascript > stuff? As one metion in the mailing list before, it would be cool if > we could collapse the header to a one-liner like in thunderbird and > things like that... > > My next idea was to use a more generic method for creating the > headers. Imagine KMail creates a xml file in memory for the header of > the mail we want to view. The file consist of all the header elements > that are available in the mail and is therefore the > representation/description of the header in xml - it describes only > the content. Now we want to put this nicely into html/css for the > user. We can use an xsltprocessor that uses an *.xsl file (our > stylesheet/template) to transform the xml into a nice html/css > representation. Since we can match some xml elements and attributes > (in the *.xsl file) we have no problems with extra elements. IMHO > that would be the cleanest way. We separate content from style and > everything seems to be possible (since we can use html/css/javascript > and what not in the *.xsl file). I implemented this with libxlst ( > http://xmlsoft.org/XSLT/ , a C library which I wrapped into a class - > but hey, maybe someone else is already using an xsltprocessor library > in the kde project?). I was close at having working stylesheet files > (*.xsl) for the current header styles (plain, fancy, enterprise...). > But then I had no time to work further on this and lost the code :/ > Although it's the cleanest way, it's somehow a little bit overkill > using a xsltprocessor?! Yes, it sounds like overkill to create XML just to convert it to HTML=20 with an XSLT processor. OTOH, if we'd go another route we'd have to=20 re-invent parts of XML+XSLT which doesn't sound like a sensible idea.=20 So if any of you wants to give this approach a try... I think it's=20 definitely worth checking out whether it's a feasible approach=20 performance- and memory-consumption-wise. > It would make more sense if we would=20 > represent the whole mail in xml. Doing this we could "export" a mail > into anything (not just html/css) just by creating stylesheet > files... =2E.., e.g. we could export to LaTeX and then with pdflatex to PDF. We'll=20 have printed email messages of the highest quality ever. ;-) I'm=20 half-joking and half-serious. =46WIW: http://englich.wordpress.com/2008/09/10/xsl-t-and-qt/ Regards, Ingo --nextPart1513396.s64eTtKBoV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkkZ9MQACgkQGnR+RTDgudiU7wCaAm/u9X0cF8zBYhleZocXiH3i KEwAoMK+sQ4wKcea5Dz2fh8897/zMq44 =3YjD -----END PGP SIGNATURE----- --nextPart1513396.s64eTtKBoV-- --===============1385615003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KDE PIM mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/ --===============1385615003==--