GNOME Bugzilla – Bug 102418
tall windows goes behind panel
Last modified: 2004-12-22 21:47:04 UTC
Package: metacity Product: metacity Synopsis: tall windows goes behind panel Severity: normal Priority: Urgent Bugzilla-Product: metacity BugBuddy-GnomeVersion: 2.0 Using fcs-07 I find that tall windows goes behind the panel. Problem is seen with staroffice windows, imagetool, sdtimage, or any gnome window for which height of window is more than the difference between top and bottom panel. To reproduce: Take netscape window. Move it down half the screen, so that bottom half goes behind bottom panel. Resize it from top so that top bar comes very near to top panel. Now drag entire window from top bar towards top side. It goes behind the top panel. You will see that now you can not access top bar, top menus of netscape. You can't even resize it. This problem was previously reported as bugtraq 4754529 "windows placed behind menu panel", which was closed as fixed, but it is back in fcs-07. Stable build 12 allowed windows to raise above the panel by clicking anywhere on a window. brian.nitz@sun.com 2002-12-19 Bugtraq+: 4796142 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-01-03 10:25 ------- Reassigning to the default owner of the component, hp@redhat.com.
Havoc: I see this bug in latest community sources. Hence marking it new. Hope it is fine.
Created attachment 13337 [details] [review] Patch should fix the bug.
Havoc: I have not completely understood constrain_position function, but I tried this fix. Do you see any side effects of this:). Please let me know.Thanks.
Well, that has its own problem that you can get the bottom of the window stuck permanently offscreen, though granted that problem is less serious. I guess we need to ask release team before applying any patches at this point.
Havoc: Based on this mail from Jeff, I guess we could go ahead. What do you think ? http://mail.gnome.org/archives/desktop-devel-list/2003-January/msg00027.html
Sounds good. Please go ahead and delete those lines of code instead of #if 0, and do ChangeLog etc. Thanks
Thanks Havoc, fixed in HEAD. 2003-01-06 Arvind Samptur <arvind.samptur@wipro.com> * src/window.c: (constrain_position) don't apply offscreen height difference. This would get the window under the panel on a resize or a move. Fixes #102418
this bugfix isn't appropriate, it creates bug 106740.
Note HP's comment from 01-03 "Well, that has its own problem that you can get the bottom of the window stuck permanently offscreen, though granted that problem is less serious." I disagree, this (introduced) problem is much more serious since it means that for many dialogs the user can never see the "close, OK, etc." buttons or other key parts of the UI - in my opinion this is a stopper. It happens for virtually all GNOME dialogs in the control-center, etc. if you pick a large desktop font and even happens for many dialogs if you have a small screen as I do (laptop,, 800x600). In general we're trying to fix non-resizeable dialogs that are more than 500 pixels high using 12pt fonts, but even if we manage that, the new behavior is a serious blocker for anything that has a large-ish minimum window size. IMO the default/initial placement of an oversized window should be independent of the user's ability to move it after the fact; this patch constrains the window positions inappropriately.
*** Bug 102095 has been marked as a duplicate of this bug. ***
*** Bug 104004 has been marked as a duplicate of this bug. ***
Applications need to not display windows that are larger than the screen. That is really the only feasible long term solution. When the user has to move a window to access buttons on the bottom we have lost big time anyway. Is there a way we can get GTK to help out with avoiding this awful problem?
Metacity can just smack down apps that are larger than the screen, but have a minimum size that's smaller. Basically, if we can shrink the window by shrinking some scrollable widget such as a text box we can do that. There's a metacity bug open to do this. The problem arises when the window's inherent layout is simply larger than the screen - i.e. when you would need to clip or otherwise break some of the widgets to make it fit. At that point, GTK and metacity are pretty much equally screwed in terms of automatically figuring out what to do. Really what's needed there is to redesign the dialog, not doable automatically on the fly. Where I'd consider addressing this (and many other UI guideline issues) is in Glade. I wish Glade had an active maintainer... Glade could complain about too-big dialogs.
The burning question is how big is "too big"... I'm not sure it would be reasonable or even feasible to force everyone to design their dialogs so they fit vertically on an 800x600 (or even a 640x480) screen when viewed with the Large Print font (currently 18 pt), but we obviously have to support users who need to run that kind of setup through choice or necessity. We also don't know in advance what panels people will have on their desktop or how big they will be, or how much bigger than 18pt a particular user might need to make their font to make their desktop usable, all of which will make the "too big" size even smaller...
My view there is that we should design dialogs for either 640x480 or 800x600 (debatable) at default font size, and go ahead and say that if you need really huge fonts you may need to have at least 1024x768. Nearly everyone has at least 1024x768 anyhow. At some point physical reality steps in; if you're blind you may need to buy extra hardware, such as a braille output device, and if you have extremely poor vision you may need to buy a decent monitor or the larger model of laptop. There's no magic software solution here, if the screen is only X inches wide and you need a font that's Y points high, only so many characters at that height will fit on the screen.
Right, but as long as "so many" is more than about one, you still have a potentially usable system... just look at your average cellphone GUI :) So, I have low vision, I'm visiting my friend's house, and I suddenly realise I have to send an urgent email (or do some other task that currently involves a big dialog). My friend runs GNOME but has an old monitor that's only capable of 800x600. Are we really happy to tell him "sorry, you'll have to use the command line for that" rather than give them the choice?
I'm happy to do it because I'm satisfied there's no reasonable alternative. We can't magically shrink a dialog layout, and we can't require all dialogs to fit in 300x200 with the default font. Do you have some sort of AI code that rearranges widgets?
Perhaps when alt-dragging we allow windows to break certain constraints? For example we could let the title bar go off-screen if the user isn't using the title bar to move the window. This ought to allow dialogs bigger than the screen resolution to at least be seem piecemeal. Of course, this would be a bit of a pain in the ass to implement. -Rob
> Do you have some sort of AI code that rearranges widgets? Nope, that's why I filed bug #106740 the other day saying "you should be able to drag windows off the top of the screen" :)
Bug 106740 seems to be more what this bug really is now. Marking this as a dupe. *** This bug has been marked as a duplicate of 106740 ***