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

[Thomas Lübking]

Hi Thomas,
Am Tuesday 23 December 2008 schrieb Thomas McGuire:
>
> pong. Sorry about the very very long delay :(
no matter. i got a little "knocked out" anyway and delayed finishing the patch 
but i'm now more or less done (even with removing the tables from objectpaser 
so that e.g. signed content can flow around images)

> > - i want to completely remove the brief/fancy/enterprise/custom
> I completely agree with this.
great, as i did. (but have to redo the enterprise style as html.inc)

> Well, about the tags: You should add all that are used by the current
> header styles.
have + there's a special placeholder $all to provide a complete list. i just 
wondered whether there are other important tags displayable in the header.

> I don't know what "!important" is, actually.
an instruction for the css parser, managing css priority.
usually every one who writes a custom css file would (in our case) have to 
append it to every css statement (background-color:black; -> background-
color:black !important;) but as my experience is, that many ppl are either 
confused by this, or (me too) tend to forget it (then wonder why it doesn't 
work as expected. wonder again... then use the f-word and fix it ;-) i 
automagically append it to every css instruction. (this takes a little 
performance - very little as the files are rather short)

> Not, nothing style-related should touch KMMessage at all. What is the
> problem with the photo URL and spam level?
just about redundant code calls. i don't know how expensive getSpamScore() is 
and currently it's called three times to handle
- the header strategy
- parsing the header include
- parsing the css
also i moved senderPicUrl() and hasSenderPic() to kmmessage to use it from 
headerstyle and headerstrategy, but as headerstrategy is now redundant, i'll 
move it back to headerStyle


> course brings the question on how the styles should be translated. 
we could add .desktop files (but that doesn't mean custom style will ship 
i18n'd from kde-look or so)
> RTL needs to be correct.
yes, adressed (i hoped that khtml using utf-8 and QString would set the 
direction automatically... well: doesn't, so the injection get's a <span 
dir="whatever">blablabla</span> instead)
however, you may expect several custom styles to popup that just don't work 
rtl (as the designer didn't take that into account) or will have to exist in 
two versions

> One solution is that the actual strings like "From" are not in the
> header.inc (like you did with "von"), but are special tags in the
> header.inc which get replaces with the real string. This doesn't allow
actually they allready are, but (as i didn't want to touch strings) end up 
"From: " (and i didn't want a colon)

> custom strings in the styles, but I think those are not needed.
well, thy can still be added but remain local. (you cannot force 3rd party 
guys)
however, as editing such includes isn't hard, i assume if there's a great 3rd 
party style with custom strings, it will be pretty small appear in localized 
versions :-)

> How is RTL stuff normally handled in HTML? Can we maybe just add an
> attribute to the div tag at runtime?
dir="" can be added everywhere and forces direction

> Ok, one big comment at the end:
> I envision this to be in a completely separate library. mostly rewritten.
yes, cleaning up this would be reasonable.

> API:
> - Getting a menu/selectaction which you can plug into your action
> collection, to select the current style. Bonus points for a small dialog
> that lets you select which header fields to show, regardless of style.
this would work with plain css styles but probably not with included headers 
(as they might not include all fields and just appending them or even just 
removing them might look silly - while removing entries is technically simple. 
we do that anyway if the message doesn't provide such field)
but we could ad a simple editor for the header.inc  and message.css to change 
headers there.

> Some comments about the patch:
> - Please don't zip patches, attach them as plain text.
isn't there a size limit?

> - Mails with signatures are actually misrendered with the demo style, see
>   attached screenshot.
i know. there was a silly bug in the html include (must have hit f2 at the 
wrong moment...)

> - When hovering over the attachment arrow thing,
> kmail:hideAttachmentQuickList is displayed in the status bar. Although I
> can't say if that was or wasn't the case before the patch as well.
probably. i didn't really change the attachmentinjection thing (it's now in a 
div rather than in a table, but that shouldn't harm?) and the string is set in 
KMReaderWin::injectAttachments()

> Since there are more people interested in this, how about splitting up the
> work at a later point? One person can do the library, one person the demo
> app, one person can do porting the old KMail styles, one person can
> (later!) try to port the applications like KMail (that would be me) and so
ok. as this is incremental, i'll start drafting a library and - to test it... 
- a simple demo app. as soon as this is basically done (i.e. compiles...) we 
can see who's with us and split workload.

Regards,
Thomas


_______________________________________________
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/