Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
Adam Fedor wrote: From: Fred Kiefer [mailto:[EMAIL PROTECTED] The code for the later change now implicitly sets the menu windows frame to the stored one (or a scaled version of that, when the screen has a different size), this could cause a problem if the menu window would be resizable, as then some menu entries might become unreachable (either because the screen is smaller or because we have new entries in the menu). At the moment this isn't a problem as menu windows don't allow resizing, but it is a hidden dependency, which may break later on. Any idea, if and what we should do here? What about when the developer changes the menu around in a new version of the app? Does that pose the same problem? Probably we should just set the origin. Also no problem as long as we have the menu marked as non-resizable. The other change also has a slight problem. The visible frame of the screen excludes a possible top menu and, if we ever have this, we must of course position the menu there. Again currently this is a no issue, I just wanted to state all these potential problems on the mailing list, so that somebody will be able to dig them up again, when this ever becomes an issue. Yep. Maybe some comments in the code would help with future changes. I add them, when I get arround to code again. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
From: Fred Kiefer [mailto:[EMAIL PROTECTED] The code for the later change now implicitly sets the menu windows frame to the stored one (or a scaled version of that, when the screen has a different size), this could cause a problem if the menu window would be resizable, as then some menu entries might become unreachable (either because the screen is smaller or because we have new entries in the menu). At the moment this isn't a problem as menu windows don't allow resizing, but it is a hidden dependency, which may break later on. Any idea, if and what we should do here? What about when the developer changes the menu around in a new version of the app? Does that pose the same problem? Probably we should just set the origin. The other change also has a slight problem. The visible frame of the screen excludes a possible top menu and, if we ever have this, we must of course position the menu there. Again currently this is a no issue, I just wanted to state all these potential problems on the mailing list, so that somebody will be able to dig them up again, when this ever becomes an issue. Yep. Maybe some comments in the code would help with future changes. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
Fred Kiefer wrote: CVSROOT: /cvsroot/gnustep Module name: gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/06/21 22:48:21 Modified files: core/gui : ChangeLog core/gui/Source: NSMenu.m Log message: Corrected handling of screen size for menu. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2541tr2=1.2542r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSMenu.m.diff?tr1=1.128tr2=1.129r1=textr2=text Sorry for having to reply to my own change mail, but when I woke up this morning I had second thoughts about the change I made last night. I made this change in NSMenu as a response to the Debian bug report #315274. Actually these are two changes, one switches from using [screen frame] to [screen visibleFrame] (and also from using the main screen to the actual screen, but this seems still correct) and the other change tries to correct the reported behaviour of the menu being off screen, when used on a smaller monitor. The code for the later change now implicitly sets the menu windows frame to the stored one (or a scaled version of that, when the screen has a different size), this could cause a problem if the menu window would be resizable, as then some menu entries might become unreachable (either because the screen is smaller or because we have new entries in the menu). At the moment this isn't a problem as menu windows don't allow resizing, but it is a hidden dependency, which may break later on. Any idea, if and what we should do here? The other change also has a slight problem. The visible frame of the screen excludes a possible top menu and, if we ever have this, we must of course position the menu there. Again currently this is a no issue, I just wanted to state all these potential problems on the mailing list, so that somebody will be able to dig them up again, when this ever becomes an issue. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
