[Kde-pim] KMail and multiple KMMainWidgets

[Ingo Klöcker]

On Thursday 29 May 2008, Szymon Stefanek wrote:
> On Thursday 29 May 2008, Ingo Klöcker wrote:
> > 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).
>
> Hehe... I acknowledge and respect the fact that you like it just as
> it is :)
>
> > > 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?
>
> Actually it wasn't meant to be a joke... but hm.. ok, ok...
> I hereby throw the middle click idea in the garbage and promise to
> never think of it again in the future :D
>
> > [...]
> > [tabbed multi folders feature]
> > [...]
> >
> > 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 it sounds as a reasonable solution to me too.
>
> > > 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.
> >
> > So what? I don't think anybody would miss the short folder list
> > (okay, a few people would certainly miss it). So I don't see a
> > problem with losing this feature.
> >
> :D
>
> I agree... others ?
>
> We'd need to choose between:
>
> - tabbing multiple Headers+MessagePreview and drop the short folder
> list - tabbing multiple Headers only
>
> > 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. :-)
>
> K. What follows does not mean to be an attack: I just did the
> experiment ;)
>
> In attachment you can find a small patch. It's a very quick and dirty
> removal of the multiple top level feature: no cleanups. It applies,
> compiles and runs on the kmail-soc branch, but you don't really need
> to apply it. Just count the lines that start with "+" and the ones
> that start with "-". You'll find that there are 50% more minuses than
> pluses. I claim that "less code" is unlikely to be more complex than
> "more code".
>
> Note that I actually did the job only for KMMainWidget and KMMainWin.
> The interesting thing is that with a single instance also most of
> other UI objects could become singletons. We could have a
> MainFolderView::self(), FavoriteFolderView::self() etc... or we could
> place the static pointers inside KMKernel which would then act as a
> "central" container...

Multiple singletons are a PITA if they depend on each other because one 
must be very careful to get the order of creation and destruction 
right. Therefore I'm in favor of the KMKernel as central container 
idea. There is no need to make them static pointers in KMKernel since 
KMKernel is already a singleton and thus there's no problem with 
storing the pointers in non-static member variables.

Hmm, thinking some more about it I don't know why we should keep 
pointers to KMMainWidget or KMMainWin in KMKernel. KMMainWidget will be 
created by either KMMainWin or KMailPart and only they should keep a 
pointer to KMMainWidget. Okay, we could also store the pointer in 
KMKernel to provide easy access to it. This would allow us to replace 
the ugly KMKernel::getKMMainWidget() method by a simple getter.

With respect to KMMainWin, we could also keep a pointer to this object 
in KMKernel, but is this actually needed? KMMainWin doesn't even exist 
if KMail is running inside Kontact. (Just thinking aloud.)


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/52fe9e6d/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/