[Kde-pim] KMail and multiple KMMainWidgets

[Carsten Burghardt]

Szymon Stefanek schrieb:
> 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).
>
>> 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' :)

I would call that a typical case of a hidden feature and the total
opposite of intuitive.

> 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.

I really like the tab idea as it also saves space. Most of the browsers
use that and I think it's a really useful feature.

> 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.

This folder selection timeout might be an option. The selection of the
message is unrelated to this as that's what the unread->read state is for.
But apart from that I'm pretty sure that there are other usecases that
include a second mainwindow. The tabbing feature would cover those I guess
but I can't imagine that it's easier to implement this than to use a
separate mainwindow.

> 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.

Right.


Regards,

Carsten

_______________________________________________
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/