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

[Michael Pyne]

On Friday 01 October 2004 10:42 pm, Frans Englich wrote:
> ...and then there's the usability aspect, which also needs to be
> questioned: Is it a valid use?

Well the times that we ignore errors in JuK, users open bugs, and rightly so.  
In this case I'm dealing with the file renamer, and I'm not going to change 
JuK to just ignore the errors.  Not that I think that this is what you were 
trying to propose.

So the user's going to see errors (if any) one way or another.  In the case of 
JuK, perhaps they accidentally specified a directory that they don't have 
write permission to, which means every rename will fail.  Which is better 
from a usability standpoint, 400 consecutive error message boxes each saying 
that foo couldn't be renamed to bar, or 1 message box containing a list of 
all the errors that occurred?  Even better would be a box containing a list 
of all the errors that occurred, and the reason for the error, but JuK isn't 
up to there yet (and that doesn't involve this patch anyways).

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

I have at least one bug report informing me that the users would rather not 
deal with 400 message boxes.  Other applications obviously may have different 
needs or uses that don't require errorList, but it's hardly my fault if they 
use my patch to break the style guide.  There's no reason to penalize 
applications that need this just because an author may use this 
inappropriately.

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

Although I appreciate your concern, I've always taken it as sort of a given 
that a good idea (informationList, questionYesNoList, etc) might lead to the 
improvement branching out into related areas (errorList in this case).

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

Actually I was thinking of submitting a patch to add a count of unread mail 
messages and new news items to the bottom of every KMessageBox, but I guess 
I'll give that up now. ;-)

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

Or perhaps it just fills out the interface to KMessageBox to add a *List() 
method to join all the other *List() methods already in KMessageBox. ;-)

> 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 would have no problems making a dialog for JuK if JuK is really the only 
application that needs this functionality.  But it would still be a message 
box, and so that would pretty much necessarily involve needless code 
duplication.

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

Again, I appreciate your concern, but I think this can only be described as a 
usability win.  No one wants to see KMessageBox expand until it can read 
mail, I assure you. ;-)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041001/4ef691c5/attachment.sig>