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

Tue Nov 11 21:10:26 GMT 2008

On Tuesday 11 November 2008, klebezettel at gmx.net wrote:
> 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?!

Yes, it sounds like overkill to create XML just to convert it to HTML 
with an XSLT processor. OTOH, if we'd go another route we'd have to 
re-invent parts of XML+XSLT which doesn't sound like a sensible idea. 
So if any of you wants to give this approach a try... I think it's 
definitely worth checking out whether it's a feasible approach 
performance- and memory-consumption-wise.

> 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...

..., e.g. we could export to LaTeX and then with pdflatex to PDF. We'll 
have printed email messages of the highest quality ever. ;-) I'm 
half-joking and half-serious.

FWIW: http://englich.wordpress.com/2008/09/10/xsl-t-and-qt/

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20081111/6c410cf2/attachment.sig>
-------------- next part --------------
_______________________________________________
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/