KMessage/KMessageHandler: a core/ui seperation for displaying message.

[Matt Rogers]

On Sunday 28 May 2006 13:35, Olivier Goffart wrote:
> Le Dimanche 28 Mai 2006 20:00, Leo Savernik a écrit :
> > Am Sonntag, 28. Mai 2006 19:06 schrieb Michaël Larouche:
> > [...]
> >
> > > So I've made the required classes to separate the message display.
> > >
> > > kdecore: KMessage and KMessageHandler
> > > KMessage is the "frontend" API static class developers use the display
> > > a message. You must supply a KMessageHandler to work properly.
> > >
> > > KMessageHandler is the abstract class for the message handle.
> > >
> > > kdeui: KMessageBoxMessageHandler and KPassivePopupMessageHandler
> > > Those are obvious, there are KMessageHandler implementation that
> > > developers can use right away.
> >
> > [...]
> >
> > That's way cool!
> >
> > I'd like to make some suggestions wrt default settings.
> > - KMessageBoxMessageHandler should be set by default in KApplication such
> > that GUI-applications work "as expected".
>
> I'd add that K*MessageHandler should not even be public API
>
> maybe
> KGlobal::setDefaultMessageHandler( enum{ StdErr, MessageBox, PassivePopup }
> ) or something similair
>

I disagree with this. While I agree that it wrong to unnecessarily bloat our 
public APIs, what reasons can you offer for K*MessageHandler not being public 
API?

> > - The default handler should write to stderr, not to stdout. Otherwise,
> > implementing filters becomes more difficult than necessary.
>
> - Another feature that can be usefull (specially for information message
> box) is the "don't show again"
>
> - using queued message box instead would be nice.
>