GNOME Bugzilla – Bug 684306
minor improvements to the not responding dialog
Last modified: 2012-10-16 12:48:27 UTC
Created attachment 224640 [details] screenshot Longer term we probably want to change the way we handle not responding windows. But as long as we have the current one we may as well make it look a bit better. It has a few problems. * Unmotivated use of italics * Two different fonts/sizes used in the heading * Strangely large * It displays the window title instead of the application name The first two are easy to fix at least.
Created attachment 224641 [details] [review] Minor improvements to the not responding dialog
Created attachment 224642 [details] screenshot (after)
Also it would be nice if the dialog appeared as a window modal dialog.
Created attachment 224664 [details] [review] utils: Request a modal dialog when transient_for is set
Review of attachment 224641 [details] [review]: This will violate string freeze. I wonder if doing something like: g_strdup_printf("“%s”", window_title); to get around that would be translatable. If you want to ask for a freeze break, go ahead. ACN if you're doing that.
Review of attachment 224664 [details] [review]: Makes sense.
Created attachment 224675 [details] [review] util: Optionally pass an icon_name to meta_show_dialog() ... ... and use a sad face in the force-quit dialog.
Review of attachment 224675 [details] [review]: I'd reverse the commit message. delete: Display a sad face in the force-quit dialog. Code looks fine.
I'm leaning towards using sad-face-symbolic but I'd like to hear Jakub's opinion.
Created attachment 224718 [details] [review] delete: Unbreak string freeze Quotes should definitively part of the translation, but we are in string freeze now - revert this when we get a string freeze approval or after the freeze ends. I didn't see a string freeze request, so let's go with this for now.
Attachment 224641 [details] pushed as 909cd82 - Minor improvements to the not responding dialog Attachment 224718 [details] pushed as 09713c5 - delete: Unbreak string freeze
Created attachment 224719 [details] [review] Revert "delete: Unbreak string freeze" This reverts commit 09713c5fd4efd123923b8c77df1a126dced96465.
Created attachment 224721 [details] lighter symbolic Symbolic might be more approproitae here, but I would not have it so dark.. how about #babdb6?
The darkness was my main concern. I like this one.
Me too, but I don't see anything we can do here (lest suggesting a very obscure option to the zenity maintainers) - I think the color is best fixed in gnome-themes-standard.
Totally doable by the theme I guess, not sure how I can select that GtkImage in that specific dialog tho, I think it needs a styleclass. Also, I'd like to avoid yet another special case, can this be a general solution somehow?
(In reply to comment #16) > Totally doable by the theme I guess, not sure how I can select that GtkImage in > that specific dialog tho, I think it needs a styleclass. If it does we have a problem - as window manager we cannot open "proper" windows, which is why we spawn zenity on the command line. A --dialog-icon-style-class option is definitively in crack territory, so I would be rather worried if we get such a patch accepted :-) (Mmmh, on the other hand, an option for the entire dialog might be acceptable, so you could match something like GtkDialog:mutter-force-quit > GtkImage) > Also, I'd like to avoid yet another special case, can this be a general solution somehow? You'll tell me :-) It would definitively be my preferred option if possible.
Why not just create a tiny custom program rather than spawning Zenity?
Running in circles is fun: http://git.gnome.org/browse/metacity/commit?id=0b3f45bb1bf8b73e4b40 :-)
Created attachment 224746 [details] [review] util: Guard against older zenity versions Plenty of ugly here, but it works; revert when the zenity version we depend on stops being bleeding-edge (or we can assume a zenity version that does not error out on unknown options).
Review of attachment 224746 [details] [review]: Ugly, but OK. If you wanted to optimize a bit, we could at least cache the result. But I suppose this code will die immediately on 3.7. ::: src/core/util.c @@ +562,3 @@ + gboolean rv; + + command = g_strdup_printf ("zenity %s", section); This is safe because you're only passing string literals here.
Attachment 224664 [details] pushed as 7e1e932 - utils: Request a modal dialog when transient_for is set Attachment 224746 [details] pushed as 5eb7274 - util: Guard against older zenity versions (In reply to comment #21) > If you wanted to optimize a bit, we could at least cache the result. But I > suppose this code will die immediately on 3.7. That's the idea, yes. I did consider caching, but it seemed a bit overkill - if we really end up displaying those dialogs a lot, something else is badly wrong.
Attachment 224719 [details] pushed as 07d8b9c - Revert "delete: Unbreak string freeze"