Created attachment 22089 [details] [review]
patch

The following patch should fix this issue.

Please review & respond if corrections are needed ;-)

I think "Restart" is a more appropriate word, from a docs
styleguide point of view.  Not sure about "Discard" either; I'd
probably just stick with the old favourite "Cancel", for this
particular message.

Also, to be completely HIG-compliant, alerts should have a primary
message in large bold text, and a secondary message in regular text. 
Suggest something like:

<large><bold>{applet-name} has quit unexpectedly.</bold></large>
This application was running on your panel.  Do you want 
to restart it now?
                                [Cancel] [Restart]

See
http://developer.gnome.org/projects/gup/hig/1.0/windows.html#alert-spacing
for required format and spacing.  Note that we don't talk about
'applets' anywhere in the UI any more, so I've tried desperately to
avoid using that word in my suggested message... other ideas welcome :)

Created attachment 22100 [details] [review]
patch2

Created attachment 22101 [details]
screenshot of patch2

Thank you Calum, here is a new patch, and a screenshot (i hope it's ok
to upload screenshot in bugzilla, since this is my first time) ;-)

I think it should now apply to HIG rules.

Looks great Laurent, to keep consistant make sure you don't
interchange "restart" with "reload".  This is such a great improvement.

I suppose the title of the dialog should not be 'gnome-panel', but
something else...

Created attachment 22102 [details] [review]
patch3

Thanks for your quick responses.

Uploaded patch3, which fixes these 2 issues; reload -> restart, and
there is no title, as defined in the HIG rules.

First of all, sorry for the late comments ...

Here is my suggestion for the text on the dialog. I have rewritten it
to hide the idea of "restart/reload," in favour of a simpler "Add".
What do you think?

"
Workspace Switcher has quit unexpectedly.

Workspace Switcher runs on a panel. Do you want to add Workspace
Switcher back to the panel?

Alternatively, right-click on a panel, then use the Add to Panel menu
to add Workspace Switcher to a panel.

                         [Cancel]   [Add to Panel]
"

Hmm, "Do you want to add <blah> back to the panel" sounds a bit clumsy
to me.  How about "Do you want to add <blah> to the panel again"?

If we're mentioning "Quit" in the dialog, though, "Restart" still
sounds like the more correct remedial action to me.  After all, you
wouldn't normally say "oh, I quit that application by mistake, I'll
need to re-add it to my desktop" :)

I see your point about quitting and restarting. But the user-visible
part of the quitting is the removal of the applet from the panel. So
we need to establish a link between the quitting and the removal from
the panel. How about this:

"
Workspace Switcher has quit unexpectedly, and has been removed from a
panel. 

Do you want to add Workspace Switcher back to the panel?

Alternatively, right-click on a panel, then use the Add to Panel menu 
to add Workspace Switcher to a panel.

                                [Cancel]   [Add to Panel]
"

Just confirming this bug . . . ignore me, please. :)

This is somewhat related to bug 127043 (UI changes to the crash report
dialog).  I mention that just in case someone wants to look at that
and make sure that the interface for these two things are similar in
whatever places it seems to make sense.

I'm also marking priority as high because of the patch(es).

*** Bug 133912 has been marked as a duplicate of this bug. ***

Long bug - current status:

  As suggested by Eugene, text should be changed to:

"<blah> has quit unexpectedly, and has been removed from a
panel. 

Do you want to add <blah> back to the panel?

Alternatively, right-click on a panel, then use the Add to Panel menu 
to add <blah> to a panel.

                                [Cancel]   [Add to Panel]
"


Laurent:

  + Could you update the patch to use the latest terminology suggested
    by Eugene ?

  + Please don't construct a message dialog by hand just because 
    GtkMessageDialog isn't HIG compliant. The correct fix it to make
    GtkMessageDialog itelf HIG compliant.

  + Punting to 2.8 because we're past the UI and string freezes and
    I don't think this is visible enough to warrant breaking the 
    freezes.

  + Re-add the PATCH keyword once you've updated the patch

Thanks ...

Created attachment 24394 [details] [review]
patch4

Created attachment 24395 [details]
screenshot of patch4

Created attachment 24396 [details]
screenshot of patch4 (real one, sorry)

Created attachment 24397 [details] [review]
patch GtkMessageDialog/HIG

Mark,

OK, I hacked GtkMessageDialog to be HIG compliant, and I modified the
previous patch according to eugene's terminology.

I added a screenshot (please ignore the first attachment, it was a
mistake).

For the GTK patch, should I submit it to gtk-devel-list as well?

Please tell me if I have to change something.

PS: bugzilla doesn't want that I add the PATCH keyword (it says that
i'm not the owner of the bug).

Still sounds wordier than it ought to be IMHO (I'd prefer to lose the
"Alternatively" sentence altogether-- this is an alert, not a user
guide), and looks odd because the button wording doesn't correspond to
any words in the message.

Anyway, I suspect that's a symptom of trying to explain an inherently
unhelpful behaviour... if a panel app quits unexpectedly, shouldn't it
just try to re-add itself silently and automatically a couple of times
before alerting the user that something is probably wrong?  It would
be much more useful to fix the behaviour than the error message...

Calum is right. It's not concise enough. Lets trash the last paragraph. Maybe
you could rework it?
Anyway, thanks for your efforts.

regs,
 Chris

Mark: I totally disagree with your proposal to fix GTK+ first. It simply isn't
feasible for GNOME 2.8, as it will be GTK+ 2.4-based.

regs,
 Chris

Created attachment 29030 [details] [review]
Proposed Patch. Practical + Feasible.

Created attachment 29031 [details]
Sample Screenshot

On the sample screenshot: the bold text should be in sentence caps (i.e. only
the first word capitalised), and to me the secondary text seemed to be a general
statement rather than suggesting what to do.. something like "Do you want to
reload it now?" might be more direct.

(FWIW, I'd still like to see the panel try to reload an applet without asking,
at least once, before popping up a dialog...)

1. I agree with Calum. The bold text sentence should observe sentence rules,
only the first word takes a capital letter. The first word being the name of the
applet in question. Also there should be a full stop at the end of the sentence.
So: "Kleberzettel has quit unexpectedly."

2. The secondary text is awkward to translate and somewhat ambiguous due to the
use of the future passive construction. Personally, I think the secondary text
is redundant. The direct imperative of the "Reload" button says everything that
the user needs to know. Save translation effort, and save the user the effort of
processing a piece of text that does not add any extra functionality to the
dialog. If necessary, we can include the secondary text in Help.

3. I think the button pair "Cancel" and "Reload" are more appropriate than
"Don't Reload" and "Reload", because "Don't Reload" seems to leave the action
open-ended. Don't Reload but leave something hanging? Also, "Don't Reload" is
going to cause translation awkardness: "Nicht Wieder Aufladen". Negative button
labels can be awkward. The extra length of the negative button could give users
the mistaken impression that there is an extra empahsis placed on that button,
and we really want them to press that button as opposed to "Reload"? Whereas
Cancel is final, clearly defined in scope, and easy to translate.

Pat

I agree with the comment about the buttons too, hadn't noticed that.  Not sure
about the full stop in the primary text... personally I think it ought to act
like a newspaper headline, which wouldn't have one (and because I think it just
looks cleaner with the bigger/bolder text)-- but we ought to say one way or the
other in the HIG, because it's come up a couple of times recently.

I was just thinking about this, I didn't realise until now there was such a
complex bug involved.

From a gnome-applets point of view, I'd love to see this dialog fixed up (I
stare at it so often). Is there going to be any movement on this before 2.8?

Created attachment 30403 [details] [review]
Proposed patch #2.

Created attachment 30404 [details]
Sample Screenshot #2

Looks good to me.  It even conforms to the new HIG recommendations for 'newpaper
headlines' :-) However we've missed the UI Freeze so we'd need permission from
the release team to sneak this in. 

Whenever Mark gets a chance to review the patch we could at least get this into HEAD

Comment on attachment 30403 [details] [review]
Proposed patch #2.

Patch looks good. Feel free to ask the release team for permission.
(marking as accepted-commit_after_freeze but it should be
accepted-commit_after_rtapproval)

Approval was rejected.

Was the GtkMessageDialog patch ever filed against gtk+?

adding the BLOCKED_BY_FREEZE keyword just to make certain it will get looked at
after.

Comment on attachment 29030 [details] [review]
Proposed Patch. Practical + Feasible.

Re-iterating the need to fix GTK+ rather than hack every message dialog in
GNOME to be HIG compliant.

There's no reason to not get this done for GTK+ 2.6 (and thus GNOME 2.10)

Sorry, I probably wasn't clear - we still need to fix up the text and such in
gnome-panel, but I don't want us messing about with the dialog's border width
and stuff ... that should be done in GTK+

Mark: Would it be user/dev-friendly if we simply changed GtkDialog's default
style information within minor releases?

regs,
 Chris

*** Bug 153316 has been marked as a duplicate of this bug. ***

Guys, I'd really appreciate it if someone would update the patch to *just* fix
the text and the buttons. No padding/layout changes thanks

Created attachment 31790 [details] [review]
Updated patch.

What about this one, Mark?

Mark?

Comment on attachment 31790 [details] [review]
Updated patch.

Ok, we need to move. It looks ok, so please commit. We'll update this again if
we have a HIG dialog...

We can't do anything more about it at the moment. As soon as GTK+ gets a
HIG-compliant GtkMessageDialog, the padding issues will vanish. Thanks for all
your efforts :).

Isn't this happening in GTK+-2.5.x?

2004-10-25  Carlos Garnacho Parro  <carlosg@gnome.org>

        Fix for #118764, David Bordoley:

        * gtk/gtkmessagedialog.[ch]
        (gtk_message_dialog_format_secondary_text),
        (gtk_message_dialog_format_secondary_format): API additions to
        create HIG-like dialogs

        * demos/gtk-demo/dialog.c: Use the new API in the example

        * docs/reference/gtk/gtk-sections.txt:
        * docs/reference/gtk/tmpl/gtkmessagedialog.sgml: documented API
        additions

I'm not refering to the secondary text API, but to the padding of GtkDialogs
(spacing between action area, window border and content area). I was told
multiple times that breaking GUI layouts is evil within minors.