[Kde-pim] KMail and multiple KMMainWidgets

[Ingo Klöcker]

On Wednesday 28 May 2008, Szymon Stefanek wrote:
> On Tuesday 27 May 2008, Ingo Klöcker wrote:
> > I'm using multiple main windows because of the fact that all new
> > messages in a folder are marked as unread as soon as one leaves
> > this folder. So when I'm reading the new messages in my inbox I
> > cannot quickly switch to another folder to look something up and
> > then switch back to my inbox because this would cause all not yet
> > read new messages in my inbox to lose their 'new' status.
> >
> > > - Would you notice if we removed the support at all ?
> >
> > Yes, I would notice.
>
> Hehe.. you were the KMail mantainer.. I bet you would notice :P
> You're also a very advanced user from this point of view.
>
> I use KMail since many years and I have discovered the "multiple
> toplevel windows" feature only once I've found it in the sources...
> (that is some weeks ago).

Being listed in the menu it's not really a hidden feature, but I guess 
most people simply never look for it because they do not expect it to 
exist. :-)


> > Note, that I do not really need multiple main windows for the
> > above, but I really want to be able to open several folders at the
> > same time. Adding folder tabs (with message list and message
> > preview pane) would be a possible alternative solution for this. Or
> > a separate folder window (i.e. a main window without the folder
> > list).
>
> I can come out with several solutions.
>
> A very simple one could be a special kind of selection: middle click
> for example. Middle Click would not remove the "new" state of
> messages when switching folders... Et voila' :)

Talking about hidden features... ;-)


> Another one (but more complex) would be to have multiple
> Headers/MessagePreview panes, as you suggest. We could implement this
> by still keeping the same unique mHeaders pointer in the sources: it
> would just point to the active tab. The inactive ones would just sit
> there "disconnected" and de-facto invisible.

Sounds reasonable.


> Yet another (but more questionable and maybe more resource consuming)
> approach would be to change a bit the meaning of the "new" flag. We
> could switch from "new" to "unread" by either reading a message
> (displaying it in the preview pane) or by a configurable timeout
> (say, 2 hours by default) and not by selecting a folder and then
> selecting another.

I don't think there's any point in changing the way it currently works. 
If I open my inbox, read a few of the new messages, then decide to go 
for a walk and then come after 2 hours, then I want to continue reading 
the new messages where I stopped. So much for a timeout causing 
messages to be switched from new to unread.


> If you think of it, the actual new->unread state change is also very
> susceptible to trivial errors: who doesn't select the wrong folder
> once in a while ? By selecting the wrong folder you loose the "new"
> status for all the messages inside.

Sure. But users will quickly learn this. Users always have to learn how 
the software handles certain things.


Regards,
Ingo
-------------- 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/20080529/38e82fb7/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/