Bug 89442 - Improved threading representation in message list pane
Summary: Improved threading representation in message list pane
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: message list (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-13 21:29 UTC by Corey
Modified: 2009-12-19 23:53 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
current behavior (82.73 KB, image/png)
2004-09-13 21:30 UTC, Corey
Details
first example (69.07 KB, image/png)
2004-09-13 21:30 UTC, Corey
Details
second mockup example (65.03 KB, image/png)
2004-09-13 21:31 UTC, Corey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Corey 2004-09-13 21:29:06 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Compiled From Sources
OS:                Linux

I think the visual representation for threads in the message list pane
could use some improvement. I've attached two mockups to help describe
what I'm hoping for.

Here's a list of the changes necessary in order to achieve the desired
results, as exemplified in the attached mockups.


1 - KListView fix, so that the alternately colored rows maintain continuity,
    rather than the current behavior which has a blocky/broken look. ( this
    is a separate bug - please refer to: http://bugs.kde.org/show_bug.cgi?id=89388 )

2 - Message flags (read,important,forwarded,etc) decoupled from Subject column. ( this is currently being worked on in a patch by Martin Koller )

--------

3 - No root list-indicator decorations. There should not be any visual 
    representation associating non-related (unthreaded) messages. 

4 - Collapse/Expand boxes _only_ at thread branches. Having col/exp boxes
    at _every_ sub-response within the thread is overkill, both visually
    as well as practicly. Instead, only provide col/exp boxes wherever the
    thread may "branch", including subject changes within the thread.

5 - No subject redundancy. It is much too busy, and entirely unnecessary, to
    have the thread subject constantly repeated and indented throughout the
    thread.

6 - As a usefull convenience mechanism, do display the thread subject when
    the message is highlighted/selected, even when the message would 
    otherwise not be shown as per #5 above.



Now, what I think may be the correct solution is to perhaps implement a new
class, overriding or inheriting from QListView or KListView - as I believe
that message threading lists are a more special/specific instance of a
regular/vanilla list.

I have attached one screenshot, and two alternative mockups below. 

The first is for reference purposes and shows the current behavior. 

The second and third are _example_ proto-types, not "perfected" - just to get
the gist across. Unfortunately, I did not apply Martin's patch before doing
these, so you won't see any separated/decoupled message flags - but I _did_
take out the flags from off the subject column.

The difference between the third and second is that the second displays the
subject at all branches, even if redundant, while the third _only_ displays
subjects if they are not redundant - even at thread branches. I'm unsure
which is "better"...

Please comment!
Comment 1 Corey 2004-09-13 21:30:01 UTC
Created attachment 7512 [details]
current behavior
Comment 2 Corey 2004-09-13 21:30:50 UTC
Created attachment 7513 [details]
first example
Comment 3 Corey 2004-09-13 21:31:30 UTC
Created attachment 7514 [details]
second mockup example
Comment 4 Andreas Gungl 2004-09-13 21:54:03 UTC
On Montag 13 September 2004 21:29, Corey wrote:
> The difference between the third and second is that the second displays
> the subject at all branches, even if redundant, while the third _only_
> displays subjects if they are not redundant - even at thread branches.
> I'm unsure which is "better"...
>
> Please comment!

Please consider the case where a thread begins above the first visible line 
in the header list. This would need some additional checks within the 
implementation.
Apart from that, both solutions are looking better than the current solution 
IMHO.

Andreas

Comment 5 Björn Ruberg 2009-12-19 23:53:13 UTC
Since KDE 4.2 there is a new UI that solves this in my opinion.