GNOME Bugzilla – Bug 120756
gok main menu shrinking
Last modified: 2004-12-22 21:47:04 UTC
using gnome-2.4 nightly from 26/08/03 .logged in as normal user. It appears that if GOK displays a UI Grab menu with a large number of buttons, when it reverts back to main the window has got smaller. If you return to the same largely populated UI Grab menu and revert again, the main menu is smaller still. e.g. - run StarOffice - run GOK - launch a new text document - hit UI Grab and a large number of widgtes are available - click back to go to main menu, and it has shrunk smaller, even as far as making the buttons illegible.
Is the largely populated UI keyboard taking up your entire screen width?
No it isn't taking up the whole screen but it is right on the left boundary of the screen. I've reproduced it with selecting 'toolbars' too, and clicking back to main. Doing this repeatedly decreases the menu size, and also the size of other gok features like the composer keyboard.
Bumping up priority, but I can't confirm this bug. Anyone else using a recent Solaris gnome environment?
I see the gok window getting snaller when I use gok with gedit. I will investigate.
I set the key width to 40 and key height to 100 and placed the "GOK-main" window in the top right hand corner of the screen. I then pressed Activate. This moved the window to the center of the screen and the key width was reduced to 18. After pressing Back the key width remained at 18. Pressing Activate again reduced the key width to 16. After pressing Back And Activate again the key width was now 13. This seems to be reproducible, for me at least. It may depend on what windows I have open. I have shown it to Bill so I have a reliable witness!
I do not see this bug on Linux. I have tried reproducing it for awhile but to no effect.
I have looked at this and wht I have seen is thatg the call to gdk_window_move_resize() in main.c results in a XMoveResize call with values (15, 0, 1257, 321) for (x, y, width, height) When a ConfigureNotify event occurs the values are (4, 19, 397, 321). Any suggestions about what could cause the window size and position to change?
I think that the problem is interaction with metacity. I hope to have more specific information later today.
The function meta_window_configure_request is called in metacity for the ConfigureRequest event. This calls meta_window_move-resize_internal which calls meta_window_constrain which causes the requested size to be changed. I do not see any obvious fix. Can someone explain how this ought to work?
when you say "meta_window_constrain which causes the requested size to be changed" I think you're kind of skipping all the interesting information. ;-) i.e. why does it cause the size to be changed. metacity verbose log (and maybe adding more debug spew to constrain.c) may turn up an answer. There's a huge comment on the top of constrain.c explaining how the file works.
Created attachment 19820 [details] [review] Debug patch
I applied the attached bug patch to constraints.c and got the following output: Constraining 0xd80002 (GOK - Wind) x_move_delta = -568 y_move_delta = -21 x_direction = 2 y_direction = 2 x_delta = 572 y_delta = 43 orig 963,53 309x126 At 1410 in constraints.c 963 53 309 126 At 1427 in constraints.c 963 53 551 126 At 1446 in constraints.c 963 53 551 169 At 1450 in constraints.c 395 53 551 169 The problem seems to be that calling constrain_resize_right before constrain_move changes the size of the window. The window was originally at the top right hand corner of the screen and it looks like constrain_resize_right find therre is not enough room for the window and so changes its size. If I call constrain_move first it wqorks for my case. It is not clear what the criteria should be for calling constrain_move first.
Havoc: if you look up in this thread you will see that the application API call which is generating bad results is 'gdk_window_move_resize'; it seems from Padraig's description that gdk_window_move_resize is sometimes failing to relocate to a 'valid' onscreen position. IOW, metacity constrains its size unnecessarily because the 'move' component causes the newly-requested onscreen coords to be within the available screen real-estate. gdk_window_move_resize just calls XMoveResizeWindow, so it's not clear to me why/if metacity tries to do the resize logic first. I guess doing our own logic and calling gdk_window_move prior to gdk_window_resize (sometimes! and other times doing the reverse) might work around the problem, but GDK clearly recommends using move_resize when both operations are being performed in response to the same application action. It looks as though Padraig has identified a case where constrain.c does not work as it should; hp can you please help investigate? Thanks
Rob, what is the bug # with all the discussion of whether to move or resize first?
Bug 106740. -Rob
yes, it does look as though this is a side-effect of the code changes for bug 106740.
Random brainstorm - is there some way to detect the case where we want to move first vs. the case where we want to resize first? I've thought about it no further than that sentence. ;-)
If the window is being moved backwards and its size is being increased I think we want to move first. I think that if we applied this for x direction it would fix the current problem.
it is my sincere hope that this is fixed in CVS. The fix will be in the upcoming Gnome 2.4.1 release shortly after Oct 13 or thereabouts.
It looks to me that this bug is fixed in metacity from CVS HEAD.
It seems that I cannot move a window whose height is greater than the screen height off the top of the screen. See bug 106740. Should I open a new bug about that?
Padraig: please reopen bug 106740.
you can only do that if 1) the window is undecorated, or 2) the window's _minimum_ size won't fit on the screen. So if the window can be resized to fit, it still enforces the onscreen top constraint. Reopen 106740 only if these conditions aren't working.