[Bug 345156] New: "Delete" is a bad default failure mode!

[gnome-panel (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=345156
 gnome-panel | Panel | Ver: 2.14.x

           Summary: "Delete" is a bad default failure mode!
           Product: gnome-panel
           Version: 2.14.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: Panel
        AssignedTo: gnome-panel-maint at gnome.bugs
        ReportedBy: sa at whiz.se
         QAContact: gnome-panel-maint at gnome.bugs
                CC: pkg-gnome-maintainers at lists.alioth.debian.org
     GNOME version: 2.13/2.14
   GNOME milestone: Unspecified


This bug was reported to the Debian BTS.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=212195

If there's a transient problem with gconf when starting up (as happens
from time to time when running unstable!), some panel inhabitants can
not be started.  When the panel then reports each of these separately
and offers to delete them, "Delete" is the default button.

This worries me for several reasons:

1. If the problem persists, there's always still time to delete the 
offending items.  If it doesn't, deleting them is a very bad choice!

2. The dialog in my case (metacity) steals the window focus.  I might
be pressing "enter" in response to something else just as the dialog
pops up.  And this particular dialog appears to be a herd animal!
A simple confirmation request takes so little information content from
the user that the risk of an accidental "confirmation" is pretty big.
This goes even for mouse interaction BTW: In my case the "Delete" 
button appeared in exactly the same place as a perfectly safe "OK" 
button from a previous dialog that I was about to click on.

3. Normally I'd expect to delete things like configuration items in a
sequence of: ((0) problem report), (1) user command, (2) confirmation 
dialog, (3) user response.  In this case it's (1) combined problem
report & confirmation dialog, (2) user response.  Confirmation requests
are even more important if interaction is not user-initiated.  

4. Onsetting dialog poisoning makes for easy mistakes.  (It would help
if all failed panel inhabitants could be reported collectively in a
single dialog.)


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.