[Kde-pim] KMail and multiple KMMainWidgets

Szymon Stefanek pragma at kvirc.net
Wed May 28 13:15:05 BST 2008


On Wednesday 28 May 2008, Carsten Burghardt wrote:

More thoughts.

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

It's true, it wouldn't be very intuitive.

On the other side this solution has the advantage of being an order
of magnitude simplier than any other solution that comes into my mind.
It could probably implemented with few dozens of lines of code.

Since actually we're trying to introduce a feature to solve a problem
that only few advanced users have (this is a keypoint that has to be verified) 
then the few dozen lines of code would be a somewhat "proportional" effort.
That is: worth it.

You put it in the tip of the day, you put it in the manual, you spread
the word... you add it as "hint" to the status bar when hovering over
the folder view...

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

Let's try to enumerate them in this thread... for now we found one:
they solve the problem of unwanted new->unread state change.

Other use cases ?

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

Yes. And it wouldn't be as easy as a middle click.

Now that I think of it, there would be also an issue with the
"short folder list" layout option: not compatible with the tabs
as I have described it in the previous mail.

Hm.. we could choose to tabify only the message header list instead of
message header list + message preview... that would be feasible.

It would be still more complex than middle click but probably
cleaner than the half-not-working multiple main windows.

But I'd really like to evaluate its real advantages.

-

In fact the multiple main windows is a problem that I have evaluated
in the past in other applications. It turned out that nearly nobody
used it and the complexity introduced by its implementation was really
wasted. With a single main window most of the "key" objects in the
app can be singletons. No need to pass hierarchy pointers around,
no need for window selection code... We could even have a single
centralized selected folder object, a single centralized previewed
message etc... 

-- 

Szymon Stefanek

------------------------------------------------------------------------------
-
- The brighter you are the more you have to learn.
-
------------------------------------------------------------------------------
_______________________________________________
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/



More information about the kde-pim mailing list