[Kde-pim] KMail and multiple KMMainWidgets

[David Faure]

On Thursday 29 May 2008, Ingo =?iso-8859-1?q?Kl=F6cker?= wrote:
> On Wednesday 28 May 2008, Szymon Stefanek wrote:
> > 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.
> 
> The implementation of multiple main windows also just takes a few lines 
> of code (if the rest of the code was designed with the possibility to 
> have multiple main windows).
> 
> 
> > 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...
> 
> You are kidding, right?
> 
> 
> > > 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.
> 
> But it's a feature most people know from their webbrowser and I'm pretty 
> sure many people would quickly start to use it.
>
>
> > 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. 

Actually, this email made me realize that multiple main windows was exactly
the solution to my wife's question the other day: how to have kmail on desktop
1 and 2, but not on desktop 3 and 4.
This way she could read private email on desktop 1, and work email on desktop 2,
to open webbrowser windows on the right desktop when clicking on a link, etc.

This reason might not be big enough for keeping the multiple-mainwindows-feature
if you guys all want it out, (since this could arguably be done by kwin instead),
but it's one possible use case for it...

> > 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...
> 
> I claim that code written with the possibility to have multiple main 
> windows in mind is cleaner than code that relies on the main window 
> being a singleton. KMail might be an exception. :-)

Yes, object orientation comes from the idea that "there could be multiple instances
of this class". Otherwise it's very tempting to write non-object-oriented code, when
everything exists only once :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
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/