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

[Thomas McGuire]

Hi Thomas,
	
On Wednesday 19 November 2008 10:23:27 Thomas Lübking wrote:
> Ok, ping and proof of concept patch attached.
pong. Sorry about the very very long delay :(

> Next steps:
>
> - i want to completely remove the brief/fancy/enterprise/custom headerstyle
> stuff and replace it with a generic headerstyle (like the current custom
> one, with some hardcoded html for the fallbacks)
> in case of the enterprise style, i'd suggest to take it out of the code and
> add it as ordinary (file based) custom style.

I completely agree with this.

> - therefore the custom style list (currently in kmreadermainwin) should
> move to headerstyle (and taken from there for the ui) and get the virtual
> brief, long, fancy things injected

> - change some of (the new) function and dir/file names (like message.css
> instead mail.css and senderPicURL instead of photoURL)
> (changing kmmessage.h triggers a complete kmail recompile... so i delayed
> that for the moment ;-)

> - i could need advice on which color roles really need to be supported
> (csshelper), which mail tags i forgot (headerstyle / headerstrategy) and if
> we should keep autoadding "!important" to the usercss files

Well, about the tags: You should add all that are used by the current header 
styles. I don't know what "!important" is, actually.

> - due to the style/strategy split we got some redundancy (i worry about the
> photourl and especially the spamlevel...)
> should we cache such values (if not already done so, but photourl can be a
> hexdata string for the image...) in kmmessage?
Not, nothing style-related should touch KMMessage at all. What is the problem 
with the photo URL and spam level?

> - atatched is a demo style, untarbz2 into e.g. ~/.kde/share/apps/kmail and
> add a "MailStyle=Demo" key to ~/.kde/share/config/kmailrc [Reader]
>
> i was about to add a combobox to the config dialog, but just figured out
> KDE's in i18n fix anyway... (another i18n thing: i18n("From: ") should
> maybe change to i18n("from") a.s.o. - css or html can append a ":" and also
> capitalize)

You can't auto-capitalize, that won't work for all languages. This of course 
brings the question on how the styles should be translated. Also. RTL needs to 
be correct.
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 custom strings in the 
styles, but I think those are not needed.
How is RTL stuff normally handled in HTML? Can we maybe just add an attribute 
to the div tag at runtime?

> last but not least: demo style (on pretty new custom html support) will
> need a little love =D

Ok, one big comment at the end:
I envision this to be in a completely separate library. mostly rewritten. This 
stuff needs to be used by Akregator and KNode as well anyway.
In my opinion, the current stuff is much too crufty for this. All the CSS 
classes, headerstyle and headerstrategy should be removed and rewritten (or 
copied were appropriate, of course).

The library should provides the following:

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.
- Saving/Restoring the current style to/from a config group
- An interface that each application should implement. That application only 
  needs to implement function like from(), photo(), hasPhoto(), spamLevel(),
  spamTooltip() etc that return the data needed by the header style library.
- One function which actually generates and returns the HTML (calling the 
  above application-implemented interface during generation to get the data).

With this API, it should be easy for application writers to use the style 
library. Did I forget some important API bits here?
The API should of course be documented, like the rest.

What do you think about this approach? IMHO it doesn't make sense to adjust 
the current KMail code to the new situation.
What would _really_ rock if you can write a smallish demo application that 
uses the library, so we can improve the library without touching KMail first. 
When that works OK, we port KNode, KMail and Akregator to the new lib.
I hope you're OK with that approach.

Some comments about the patch:
- Please don't zip patches, attach them as plain text.
- Mails with signatures are actually misrendered with the demo style, see 
  attached screenshot.
- 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.
- Coding style: Please follow the KDEPIM one, e.g. spaces inside or 
  parenthesis. No German comments. All functions documented in the headers.

Thanks very much for the initial patch and again, sorry for the long delay, I 
can only do a fraction of the things that are on my to do list currently.

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

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmail-style-misrender.png
Type: image/png
Size: 65667 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20081223/8cf2edb3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20081223/8cf2edb3/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/