GNOME Bugzilla – Bug 144490
Incorrect position of volume dialog
Last modified: 2004-12-22 21:47:04 UTC
1. Change volume or mute 2. Dialog shows up in top left corner (0x0) 3. Change volume again (before the windows dissappears) 4. Dialog shows up where it should
Created attachment 28779 [details] [review] Delayed position If the move of the window is delayed until after the window is shown it works. I don't know enough GTK to speculate why that is but this patch at least solves the problem.
I see this too in 2.7.x (jhbuild) and 2.6.x. Updating version. Bug has patch, changing prio to High.
2.7 code freeze is arriving for control center too, what's happenning with this? I think it's a quite annoying and visible bug
Fix is fine, and obviously non-destructive. Please write a changelog entry and commit.
Commited, thanks :)
The patch is a rather dirty fix. Perhaps a new bug should be opened that finds the real cause of this problem? With the current patch one can still see the window appear briefly in the top left corner.
I think I have a correct solution in hand (at least as I checked with GTK API docs).
Created attachment 31504 [details] [review] Fix the initial position of the dialog window This patch is against 2.6.1.
Comment on attachment 31504 [details] [review] Fix the initial position of the dialog window >--- control-center-2.6.1/gnome-settings-daemon/gnome-settings-multimedia-keys.c.location 2004-09-11 11:08:29.000000000 +0200 >+++ control-center-2.6.1/gnome-settings-daemon/gnome-settings-multimedia-keys.c 2004-09-11 11:59:10.006083352 +0200 >@@ -539,13 +539,9 @@ > x = ((screen_w - orig_w) / 2) + geometry.x; > y = geometry.y + (screen_h / 2) + (screen_h / 2 - orig_h) / 2; > >- gdk_window_move (GTK_WIDGET (acme->dialog)->window, x, y); >+ gtk_window_move (acme->dialog, x, y); You are missing a GTK_WINDOW around acme->dialog otherwise you get a warning at compile time. But it is in fact the real fix for the bug (it wasn't moving gdk_window_move after gtk_widget_show but use gtk_window_move instead, and call it *before* gtk_widget_show. > >- gtk_widget_show (acme->dialog); >- >- /* this makes sure the dialog is actually shown */ >- while (gtk_events_pending()) >- gtk_main_iteration(); >+ gtk_widget_show_now (acme->dialog); Not needed, and the code is exactly the same (look at _show_now code) So, real fix is gtk_window_move (GTK_WINDOW (acme->dialog), x, y); gtk_widget_show (acme->dialog); and keep the while loop. > > acme->dialog_timeout = gtk_timeout_add (DIALOG_TIMEOUT, > (GtkFunction) dialog_hide, acme);
Cheers guys, I wasn't even CC: on that bug... What I can tell you is that the original piece of code used to work on acme stand-alone, and in all the version that I saw afterwards. But it seems that it might have been broken with a recent gtk+.
2004-09-29 Bastien Nocera <hadess@hadess.net> * gnome-settings-multimedia-keys.c: (dialog_show): rework the dialog_show so that the dialog is moved before it's shown, and use gdk_display_sync() instead of a event looping to avoid "reentrancy" problems when showing/hiding the dialog in fast successions (Closes: #144490) Re-open if you have any problems with the current CVS code, thanks.
Would not a calling of gtk_window_show_now be a better solution than gdk_display_sync?
*** Bug 152923 has been marked as a duplicate of this bug. ***