Version: (using KDE KDE 3.5.3) Installed from: Ubuntu Packages OS: Linux When viewing all message headers, it can be useful to have some text formatting to annotate the headers and make them more readable and easier to parse visually. The formatting I have in mined includes: 1. <b> for: From, To and CC. 2. <b> + <u> for: Subject. 3. border-top + border-bottom for: multi-line headers such as Received to group them together. 4. <hr> at the end of the headers. The rational for the first 2 points is that these are popular fields, and it makes it easier to correlate the "All Headers" view with more popular views such as "Fancy Headers". The rational behind the 3rd point is, that (for me) the best reason to use "All Headers", is to follow the SMTP hops. I found that the borders make this task simpler. I am not sure about point #4, but it gives better separation between the message header and the body. This separation become more important because once the headers aren't a mere chunk of uniform text, a simple margin may be insufficient.
Created attachment 16782 [details] screen shot of the formatted all-headers In this shot the <hr> separator is not shown.
Created attachment 16783 [details] Add formatting for "All Headers" view This patch is against branches/KDE/3.5. And for my next trick I will try to make this configurable. May I have a volunteer from the crowd? :)
I'm sorry, but we don't want to add any formatting. "All Headers" should just show all headers without any _fancy_ formatting. That's what we have "Fancy Headers" for. If you want to work in this direction then please come up with a general solution which would allow us to get rid of all the different header implementations and replace them with some implementation which uses templates/styles. A crucial requirement is that installing/changing styles must be possible without touching the source code. In a first step a style will probably consist of two parts: The HTML template and the corresponding CSS definitions.
As I see it, creating a generalized header implementation, is actually two problems. There are in fact two distinct types of header the user may want to use: 1. Raw headers: untranslated, with no strict order. (all headers) 2. Structured headers: translated with support for direction=rtl, with selected fields placed in well defined positions. (all other headers) While it may be possible to generalize both types into one solution, some initial sketches of such design, suggest this will be over complicated, both to program, and for designing header style templates. I hope that with this bug, I at least demonstrate the usefulness of applying some formatting to type-1 headers. So if I break the generalization problem into two smaller problems, I will be able to hack on a configurable version of the above patch, with a default configuration of no special formatting at all. In this case I will leave the generalization for type-2 headers for later. Regardless, when I look into such type-2 solution, I am yet unsure of the way of including i18n into it's design. Saying all that, my question is whether such type-1 patch may be accepted, with or without type-2 patch. Although I cherish the learning experience, it will be nice to know weather this work stand a chance of being checked in. Cheers, Chen.
I agree that it's most likely better to split this into two implementations. The problem with a configurable version of your patch is over-configurability. I'd prefer to either apply it as is, i.e. without making it configurable, or to reject it. Comments on the patch: + QString fl = static_cast<QString>(field->FieldNameStr().c_str()).lower(); This looks extremely fishy. You are casting a char * to a QString. I really wonder why your compiler seems to accept this. Better use + QString fl = QString::fromAscii( field->FieldNameStr().c_str() ).lower(); + if ( inMultiLine && ! fl.startsWith(" ") ) { A continuation can also start with a tab character. So better use + const bool isContinuation = ( fl[0] == ' ' || fl[0] == '\t' ); + if ( inMultiLine && !isContinuation ) { I think the <div> is not properly closed if the last header line is a Received header, i.e. something like + if ( inMultiLine ) { + // end multi-line + result += "</div>\n"; + } is missing after the for-loop. I dislike underlining the subject. Please don't use tab characters for indentation. I don't think the formatting is useful in a printout. Therefore for printing the CSS definitions of multiline-first/next should be omitted.
Created attachment 16792 [details] Fixed patch for add formatting for "All Headers" view I hope this addresses all the specific points Ingo had raised. A notable change is that I figured that a multi-line field is actually a single field. This allowed for some stream-lining, and perhaps will allow for some more generalization, if I will be able to address the big issue (see next comments).
Created attachment 16794 [details] Mockup of all header display using a zebra colors I guess that Ingo is right to point out that users expect all-headers to be in plain formatting. I can argue as long and hard as I wish that my design is superior, but there will always be users who will get pissed off if at the very least they will not have a way to turn that feature off. So in an effort to minimize the configurability I suggest a zebra view. And here is the rational: * Zebra colors is a common way to show list, and all-header is virtually a list. * With it we don't have to specify which field should be surrounded by borders (one less thing). I am still convinced that marking some fields with bold is helpful, but the KDE way as I understand it is not forcing the developers opinion on the users, so at least an off switch is in order. Without it, I think, it will be better to drop the hole thing. Cheers, Chen.
I like the zebra colors in the mockup.
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.