GNOME Bugzilla – Bug 589632
gnome-panel doesn't start
Last modified: 2009-08-20 12:49:50 UTC
So today I logged into a normal gnome session after using the shell the last couple of weeks. When I logged in, the panel didn't start. Well it started, but it didn't show any panels. So I got out gdb and determined it was blowing this assertion: g_return_val_if_fail (monitor >= 0 && monitor < monitors [n_screen], 0); in panel_multiscreen_width (likewise _height, _x, _y etc) I then started snooping around in gconf and sure enough, my panel's monitor key was set to "1" even though there is no monitor 1 right now. There probably was the last time I logged out with gnome-panel. I guess we should move panels from non-existing monitors to existing ones.
Created attachment 139169 [details] [review] potential patch This patch just checks if a panel's monitor exists. If it doesn't then it sets the panel to use monitor 0. Some other idea: - We could potentially only set the monitor temporarily to 0 instead of writing it to gconf, so things behave a little better when going back to multimonitor setup - we could also potentially just temporarily disable the panel instead of moving it, if monitor 0 already has panels On the other hand, I don't think we should get too sophisticated here, because storing monitor number in gconf is fundamentally broken anyway, since the monitor numbers aren't guaranteed to be stable.
Created attachment 140541 [details] [review] [panel] Do not use non-existing monitors for toplevels We just use the previous monitor instead, without changing the configuration.
Created attachment 140542 [details] [review] [panel] Do not save monitor changes that are caused by constraints We only want to save changes that are made by the user.
Ray, can you try those patches: they should do the right thing for you. Restarting the panel with the other monitor plugged should make the panel move back to the right place. FWIW, it's working fine in stable releases, because we're just hitting a critical warning here. One thing we should also do is to have the panel-multiscreen infrastructure send a signal when things have changed, so that we can move the toplevels to the right place dynamically. Shouldn't be too hard to do.
Created attachment 140549 [details] [review] [panel] Move the toplevel to its configured monitor if it appears When a new monitor appears, all toplevels get a size request. So the first thing we do during this size request is checking whether the monitor of the toplevel is the same as the one it's configured to be on.
This should add the last part to make it automatically work if you add your monitor at runtime. I can only tell you it works with one monitor :-) (I don't have a second monitor here) Can you test all this?
In brief testing, the patchset doesn't seem to work quite right. If I turn off my external monitor its panels jump to my laptop panel, then if I turn it back on the panels don't jump back to it. If I turn off my laptop panel its panels jump to my external monitor, then if I turn it back on all of the panels (including the ones configured for the external monitor) jump to the laptop panel. I haven't given it any more investigation than that, yet, though.
Created attachment 140788 [details] [review] [panel] Keep in memory the configured monitor for a toplevel We were forgetting the configured monitor, which meant that after a monitor disappears once, we cannot go back to what the user really configured once the monitor appears again.
Still not quite right. The panels move around as monitors come and go, but they always jump to the top of the screen (even bottom panels). Also I'm not getting the critical again: ** (gnome-panel:18221): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed and metacity is getting wordy: Window manager warning: struts occupy an unusually large percentage of the screen; available remaining width = -1 < 100Window manager warning: struts occupy an unusually large percentage of the screen; available remaining height = -1 < 100
(In reply to comment #9) > Still not quite right. > > The panels move around as monitors come and go, but they always jump to the top > of the screen (even bottom panels). Okay. I think we reached the point where I really need another screen to test this. Will try to find one. Thanks!
(In reply to comment #9) > Still not quite right. > > The panels move around as monitors come and go, but they always jump to the top > of the screen (even bottom panels). I don't see this. It works fine for me here (with a new patch to fix the critical warning you had in the same comment).
Created attachment 141171 [details] [review] Patch (covers all previous patches) git-bz doesn't work with the new bugzilla, so here's the patch showing the diff between my branch and master.
Okay, committed. I agree with what you said on IRC (the fact that it's still broken in various ways), but at least this fixes the critical warning and should work much better.