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

[Thomas McGuire]

Hi,

On Tuesday 23 December 2008 14:08:18 Thomas Lübking wrote:

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

Yes, that is a good idea, and would save us from the dilemma whether to use 
"From" with or without colon, lowercase or uppercase. For custom additional 
header fields, we still need the application to provide a list (see below), 
but that is ok.

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

Looks like we can't prevent that the style looks silly when removing a field.
About appending a field: It seems we can't know all fields in advance, how 
about a special injection point were all additional fields we don't know about 
are added, something like $additionalheaders? The interface which the 
application has to implement then should have two new functions, one that 
returns the field names of the additional headers (so one can disable them, 
this would solve the KNode case) and one that returns the value of a specified 
additional header field.
I think a header.inc or message.css editor would be a bit overkill for this.
The best thing is probably to play with the demo app and the library a bit to 
experiment.


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

Probably several kilobytes, .diff files are not that big.

> > - 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()

It is a bug in KMail actually, the enterprise style has the same problem.

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

Ok, great. I look forward to that, we can then add it to playground in svn 
where it can be polished and where we can do experiments.

Regards,
Thomas
-------------- 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/286a0e28/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/