GNOME Bugzilla – Bug 91686
Menu panel resizing problems when changing font size
Last modified: 2015-03-24 13:00:35 UTC
The menu panel (along with all other panels) now seems to resize when you choose a theme with a large font, but it doesn't always take effect immediately. If I do a "pkill panel", however, it respawns with the correct size. Likewise, if I go back to a theme with a smaller font, the menu panel doesn't get smaller until it restarts. All other panels react instantly.
Actually, "all other panels react instantly" only seems to be true on Linux. On Sun's Solaris beta 2 build 5, non-menu panels do not resize at all, even after killing and restarting the panel.
Shouldn't be resizing at all if it isn't going to work consistently :/
Hmm, this seems to be working fine and dandy for me today, now that I've removed some duff old accessibility themes from my path that it seemed to be picking up instead of the latest ones. Will keep an eye on it for a few days just in case though.
Great, now the edge panels are resizing properly but the menu panel's stopped resizing again :/
yes, this seems like a regression. what's happening with this bug?
Created attachment 11628 [details] [review] foobar resizing patch
Hey Mark, Okay, this patch is pretty crufty, because I'm not 100% sure of what is going on - and obviously, what I'm doing. Some points about the patch - So we do a size request and override it in the allocation phase - basep seems to do this as well [leads me to think the size_request bit is unneccessary]. For some reason, I'm getting weird width requests and I'm having trouble figuring out why - as a result, I'm basically ignoring the request width at the allocation phase. I'm not sure how the multiscreen stuff works - it could just be a copy and paste of the code in basep, but haven't included it yet.
Glynn: it was far from obvious to me what was causing this so I ended up having to look at it in detail. I've come up with a (hopefully) correct patch and committed it to gnome-2-0 and HEAD. Thanks ... 2002-10-18 Mark McLoughlin <mark@skynet.ie> Fixes #91686. Based on a patch from Glynn. * foobar-widget.c: (foobar_widget_class_init): hook up size_request. (foobar_widget_screen_size_changed): don't set width request here. (foobar_widget_size_allocate): don't set the size hints here. (foobar_widget_size_request): size size hints here and resize the window if neccessary (foobar_widget_new): don't set width request here.
The fix looks great dude - thanks for having a look at it. The whole thing was puzzling me for quite some time because I didn't know how things were propagated up the widget heirarchy wrt size requests and allocations. Good stuff ;)
In sun build fcs-02, menu panel sizing now works (except that the clock gets chopped), but edge panel sizing doesn't... could it be this patch that's broken it...?
Calum: what do mean by "edge panel resizing doesn't work"? If its that the applet isn't resizing the panel then its the same issue as the "clock chopped" thing.
Yeah, that's what I meant, seems to be fixed in fcs-07.
Updating status whiteboard with a11y impact if this isn't fixed yet (presumably for GNOME 2.2 only, as menu panels don't exist any more... but Sun's next release might still be using gnome-panel 2.2)
On 2.2 this seems to be a problem for edge panel only. When I change theme to Large Print theme the text in Window list applet and clock applet is chopped. This does not seem to be a problem for menu panel. When using gnome-panel from CVS HEAD there is no problem.
I don't think we can/should use panel-2.2. If that's agreed then we should take this bug off the AP radar.
Removed AP notation; this means that we must use panel 2.4 in order to get good accessibility.
Removing accessibility keyword as well, then, to keep it off our buglist.
Hold on. Forget removing keywords and stuff. This is fixed on HEAD right ?
Seems to be, but the bug was filed against 2.2, not head :)