[Kde-pim] user css controlled mail appereance... reload.

[klebezettel at gmx.net]

On Sunday 09 November 2008 21:22:22 Thomas Lübking 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?! It would make more sense if 
we would represent the whole mail in xml. Doing this we could "export" 
a mail into anything (not just html/css) just by creating stylesheet 
files...

Please describe your html/css approach detailed. What do think you about 
the xml/xlst stuff?

Regards,
	Klebezettel :)
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/