[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Fix for marking messages in collapsed threads
From:       Ingo =?utf-8?q?Kl=C3=B6cker?= <kloecker () kde ! org>
Date:       2005-03-12 1:50:45
Message-ID: 200503120250.50935 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 11 March 2005 18:02, Till Adam wrote:
> On Friday 11 March 2005 17:35, Allen Winter wrote:
> > On Friday 11 March 2005 11:25 am, Will Stephenson wrote:
> > > Mark Message-> in header view currently marks the message and any
> > > collapsed child thread under it.  Is this the intended behaviour,
> > > or should that action only mark the visible selected messages,
> > > and Mark Thread be used for marking threads?
> > >
> > > The attached patch makes Mark Message only mark the visible top
> > > of a collapsed thread.
> > >
> > > However, there's a bit of a gap there, because Mark Thread marks
> > > the whole thread, parents included, whereas Mark Message could be
> > > used to mark subthreads by collapsing and marking them.
>
> Hm, when we introduced the "parent of a collapsed thread represents
> the whole thread" semantics for move and such we discussed this, I
> seem to remember, and came to the conclusion that it should be
> consistent with the other operations on parents of closed threads.
> The reasoning being that a collapsed thread is a grouping which can
> be toggled by the user. So I think things should stay as is here, if
> only for consistency.

Yes, that was our reasoning. But each time I mark the root message of a 
collapsed thread as important I'm annoyed by this behavior. OTOH, I 
can't remember to have ever used this feature to mark all messages of a 
thread. So now that we have tested this behavior for some time I came 
to the conclusion that marking all messages of a collapsed subthread 
doesn't make sense (especially because there's a separate action for 
this).

The problem is that this can't be fixed that easily because internally 
we select all messages of a collapsed (sub)thread if the root of the 
(sub)thread is selected. This makes all actions automatically work on 
all messages of a collapsed thread (because they work on all selected 
messages) which is a nice and clean solution. Now Will's patch works 
around this automatic collapsed-subthread-selection making the code 
more complicated. (BTW, why did you convert the for-loop into a 
while-loop?) A cleaner solution would probably be the introduction of 
an additional "selected and shown" status (where "shown" means the 
message is not "hidden" inside a collapsed thread).

Other actions for which the behavior doesn't make that much sense are 
the various Reply actions. Did anyone ever want to reply to all 
messages of a thread? OTOH, for the Forward actions is makes sense. So 
the question is whether it's desirable to introduce inconsistency. In 
the end I think it boils down to the expectation of our users. How do 
they expect KMail to work? Do they have different expectations for 
different actions?

> > Related to this ... I noticed if new messages come into a thread
> > already marked (important, to-do, whatever) that the new messages
> > don't get marked. I think new messages in a thread should
> > automatically receive the same marks as their parent message.
>
> This happens for "Watch Thread" and "Ignore Thread", but not for the
> others, and I think that's correct. I often mark individual mails in
> a thread as Todo or Important and would not want children to inherit
> that flag.

It makes even less sense with Replied, Forwarded and Sent.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]