[PATCH] Add errorList() and errorListWId() to KMessageBox

[Frans Englich]

On Saturday 02 October 2004 02:10, Michael Pyne wrote:
> Hi all,
>
> Attached is a patch to kdelibs/kdeui/kmessagebox.{h,cpp} that adds support
> for the errorList() and errorListWId() convienience functions to
> KMessageBox.  I would like this support for JuK, as there are a few code
> paths that process a bunch of files sequentially, and each file may have an
> error.
>
> This is currently handled by either reporting the errors in separate
> message boxes (which is what I'm fixing right now, imagine 50 error message
> boxes in a row!), coercing a QStringList into a QString joined by newlines
> (this can make the end dialog needlessly tall), or by using a different
> dialog that does provide a list (which loses the "Error" property).
>
> The functions are all static, so there should be no problem with binary
> compatibility.
>
> Please let me know if it is alright for me to commit this.

...and then there's the usability aspect, which also needs to be questioned: 
Is it a valid use?

It assumes that many different messages can be treated as one readonly unit, 
and that the user is not interested in a more fine grained interaction. It 
could easily lead to a development direction where the message box isn't any 
longer a quick, atomic, message, but becomes a large "main window" with deep 
user interaction. 

A design's(the message box) initial role have been widened, and that could 
continue towards feature creep. For example, the next time it is perhaps a 
patch which extends this patch to have editing fields. 

AFAICT, what it boils down to is what purpose a message box has. If it 
contains much information, that implies it have become a working area, and 
that suggests the user for example switches between different 
applications(for various reasons). Perhaps the message box isn't intended for 
that -- it doesn't show up in the taskbar, for example.

Perhaps it is a "dangerous" patch, which opens up for misuse, difficult 
developer decisions, and potential feature creep -- more negative points than 
those rare(?), special cases it solves. Feedback for batch processing isn't a 
new issue, I can think of tables and lists as ordinary widgets. Perhaps it 
should be solved "in" the application.

I don't know, I'm just thinking out loud.


Cheers,

		Frans