[Kde-pim] KMail and multiple KMMainWidgets

[Szymon Stefanek]

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

We could also avoid passing these object pointers around to any single
child or worker class...

We could avoid the ugly "temporary window" hacks in KMKernel..

etc...

And this is just a 20 minute brain work.


-- 

Szymon Stefanek

------------------------------------------------------------------------------
-
- Parkinson's Law:
-   Data expands to fill the space available for storage.
-
------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmail.singletons.diff.bz2
Type: application/x-bzip2
Size: 5968 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080529/0eb29908/attachment.bin>
-------------- 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/