Summary: | use smarter format for the message header when viewing "All Headers" | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | Levy, Chen <kde> |
Component: | GUI | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WAITINGFORINFO | ||
Severity: | wishlist | CC: | luigi.toscano |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
screen shot of the formatted all-headers
Add formatting for "All Headers" view Fixed patch for add formatting for "All Headers" view Mockup of all header display using a zebra colors |
Description
Levy, Chen
2006-06-25 09:39:18 UTC
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. |