Timeout for KMessageBox (Was: Patch for KMessageBox)

[Reinhold Kainhofer]

Waldo Bastian wrote:

> On Monday 12 May 2003 15:05, Daniel Naber wrote:
>> I think a timeout dialog is just a usability problem in most cases. It
>> needs some visual feedback to show users that there is a timeout, but
>> this will tell the user to hurry up ("enter you password in 5 seconds or
>> bad things will happen").
> 
> MacOS X uses it for the logout dialog. If you don't confirm within XXX
> seconds, it will log you out anyway.
> 
> I'm not opposed to them in general but I'm not sure in which cases it
> would make sense to use them (the kpilot case seems ok) and how they
> should behave, e.g. which action should be taken after the timeout?

Hmm, to take the issue even further, I was actually thinking of implementing
it in a very general manner, not specific to timeouts. Currently, you
cannot do anything with a message box, because you never get the
KDialogBase pointer for it. My idea was a 
class KMessageBoxHelper {
  KMessageBoxHelper() {};
  virtual ~KMessageBoxHelper() {};
  virtual customize(KDialogBase*messagebox) {};
}
base class, which one can subclass and pass a pointer to the static
KMessageBox methods. Right before executing the dialog, the customize
method of the helper class would be called with the pointer to the
messagebox. Now in the customize method, one can connect a timer to the
cancel slot (or whatever slot is desired). 

Of course, all static KMessageBox methods would need an additional argument
KMessageBoxHelper*helper=NULL (but something similar would be needed
anyway). Also, I'm aware that this opens so many ways to mess with
messagebox that a programmer can easily cause havoc at least for his
application.
If instead of =NULL, we use a global static
KMessageBoxHelper*defaultMessagBoxHelper, all message boxes could be
customized the same way. But this probably would give every application
developer too much power over a core component like KMessageBox.

Reinhold