GNOME Bugzilla – Bug 165197
Try to make windows fit on the screen when mapped
Last modified: 2006-08-04 11:33:20 UTC
Please describe the problem: Menus and windows cannot be moved farther when they reach to the top of the screen (I'm speaking of moving them using alt+mouse). This causes some problems, e.g. with mozilla preferences menu, you cannot press the OK button. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Yes. Other information: Thank you for your notice, Bahram Alinezhad, Registered linux user #375283 (counter.li.org) Rudehen, Tehran, Iran.
Why can't you press the OK button? Is the window too big to fit on the screen?
Yes, in 640x480. Thank you for your notice, Bahram Alinezhad, Rudehen, Tehran, Iran.
What version of Metacity are you running? Can you resize the window so that the OK button fits on the screen? (Note to self--may be prior to bug 106740, a regression since then, or just not utilizing the functionality from that bug; see also bug 152898)
Dear Elijah, Reviewing those reports, I am disappointed to report more bugs. For example, consider bug 106740: All are trying to convince a developer (i.e. Havoc Pennington) to remove the annoying constraint, but he resists and finally accepts to apply some exceptions; Even so, we see NO solution at all after two years! Sorry! I apologize for saying so and you may correct me right; But now, I cannot access some parts of some programs because somebody feels the horror of losing the title-bar!!
Bahram, yes, there has been a solution and others are being considered. However, you have ignored my questions, so let me repeat them: What version of Metacity are you running? Can you resize the window so that the OK button fits on the screen?
The current intended behavior is that if a window is too large for the screen, you can move the titlebar off the screen to see the bottom, iirc.
That's what I thought too, but I checked the code after Bahram filed this bug. It appears that what you said isn't quite true; from constraints.c: /* if the window has a minimum size too big for the "effective" work * area let it "cheat" a little by allowing a user to move it up so * that you can see the bottom of the window. */ So it appears that you can move the titlebar off the screen only if the window is too large for the screen AND you can't resize the window so that it will fit.
Ah OK. Alan Cox has been complaining forever that we don't automatically force windows to fit if they map themselves too large and are resizable. I don't know if there was a reason we don't do that or if we've just never gotten around to it.
Hello Elijah, Hello Havoc, ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Elijah Newren" (newren@gmail.com) wrote: ---------- Bahram, yes, there has been a solution and others are being considered. However, you have ignored my questions, so let me repeat them: What version of Metacity are you running? Can you resize the window so that the OK button fits on the screen? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<- 1- On right up corner of the report, please scroll up to see the version. 2- Resizing this window makes some parts of it unavailable. You can examine it yourself: It is "mozilla preferences menu" in 640x480. When one speaks about a bug, you should not go around his particular example; Assume that in a newer version of mozilla, they add a scroll-bar to the preferences menu so I can access all parts easily, but, has the bug of metacity solved? No, because that was only one instance and other instances may be found. I cannot remember correctly, but I saw some games also suffer this limitation. Avoiding the windows to move up freely causes another bad problem: Suppose you have two windows and want to carry some text from one to another by dragging (or even by copy/paste), and for some reason, this should be done multiple times; Then, it is best to place them in a situation that there is no need to switch between windows. In this case, it is desired that there be no restriction in moving them. Finally, I believe a bug shouldn't be fixed by adding exceptions to general rules; My reason is that any exception can be the origin of newer bugs in the future, since, a developer should consider all those exceptions in the new features he wants to add. In addition, adding exceptions, increases the code volume and slows down the performance. This is better to change the general rules at the orientation of having fewer problems, not to add exceptions. I saw a comment about "edge limitation of move" that was great: You can move *any* window off the screen in *any* direction provided that it has at least N pixels inside the screen. The above idea is just an example of a solution for the fear of losing windows, and is a "general rule" because it uses "*any*" terms. I am sure that you can think out even better general rules than that. Too long comment, excuse me! Thank you for your notice, Bahram Alinezhad, Rudehen, Tehran, Iran.
Havoc: That hadn't occurred to me (I guess because I only run with bigger resolutions), but I think it's a really good idea for the the same reason we automatically raise windows on click: it's counter-intuitive to expect users to want to work with an obscured window. Bahram: > Resizing this window makes some parts of it unavailable. That would be a Mozilla bug. They should set a minimum size hint; if they had done so, you would have been allowed to move the window off the screen. Of course, it was bad that we made you do the working of resizing, when obviously you'd want to do that as long as it didn't violate some minimize size. So I think we should add a general rule: try to make the window fit on the screen if it can. ;-) I'm going to retitle this bug about the make-windows-fit since there isn't another bug open about it, and we already have bug 152898 to cover anything else.
->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That would be a Mozilla bug. They should set a minimum size hint; if they had done so, you would have been allowed to move the window off the screen. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<- I didn't understand some parts of your response: -What is "minimum size hint"? ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Of course, it was bad that we made you do the working of resizing, when obviously you'd want to do that as long as it didn't violate some minimize size. So I think we should add a general rule: try to make the window fit on the screen if it can. ;-) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<- -What means "violate some minimize size"? -What means "make the window fit on the screen"? Zoom out on it?! ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm going to retitle this bug about the make-windows-fit since there isn't another bug open about it, and we already have bug 152898 to cover anything else. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<- Can I hope a solution for my problem in next gnome version? Regards
> What is "minimum size hint"? See http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html#XSizeHints to learn more about size hints, including the minimium size hint. > What means "violate some minimize size"? To violate a minimium size would mean resizing the window so that it was smaller than what the app said it should be made. > What means "make the window fit on the screen"? Zoom out on it?! Not zoom--resize. > Can I hope a solution for my problem in next gnome version? Depends on whether you can get Mozilla to fix their bug. I think it's reasonable for us to try to fix our half before the next major release (it would seem annoying to most users to try to manipulate an object they can't see, so it seems reasonable that we should resize windows if allowed--and not doing so should be considered a bug); I'll throw it on the 2.10 milestone. No guarantees, though, especially since the next Gnome version is coming up really soon...
Ah, just noticed that this is a dupe. *** This bug has been marked as a duplicate of 143145 ***
- If mozilla should be reported for such a bug, who can convince them? I think you are the best to do so. - "2.10"?!! The version after "2.9" seems to be "3.0", not "2.1" ;-) Thank you for your notice, Bahram Alinezhad, Rudehen, Tehran, Iran.
Nautilus 2.14.0 on Fedora 5 is OK. Thank you for your notice, Bahram Alinezhad, Registered linux user #375283 (counter.li.org) Rudehen, Tehran, Iran.