Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r9084) Fixed in Subversion repository. Fixed together with STR#2697. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r9084) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) NOTE: There is work in #2697 to create the necessary work_area methods (thanks Manolo) that we should be able to use to get a better overall solution to this one, I think... Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) @Manolo: yes, the menu is now positioned correctly, but this still doesn't resolve the whole problem, since the menu doesn't scroll on *my* special display setup: monitor 1: 1680x1050 (with taskbar), monitor 2: 1440x900 (w/o taskbar). Both monitors have their zero y coordinates in line, and hence the lower part (higher y coordinates) is missing on monitor 2. As Ian noted, Fl::x()/y()/w()/h() *should* be platform-independent, and adding another "#ifdef __APPLE__" in Fl_Menu.cxx (r 8935) should IMHO be avoided, if we can. However, rev. 8935 solves the issue maybe on most platforms or standard display setups and is at least a step forward... Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) I don't have enough (or indeed any!) different multi-head systems to test, but is Manolo right that the behaviour of the Fl::x(),y(),w()h() methods on a multi-head system is different depending on what host system you are on? If so, we *need* to fix that - these methods *have* to be consistent across hosts as they are used all over the place... And yes, this is off-topic for this STR. I'll raise a new one. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) With r.8935, the menu stays on the correct screen when using multiple screens and MSWindows. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) BTW: I don't think that this would be okay on X11 with Xinerama, but I can't test this right now. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) Monolo, unfortunately this is an even major regression on Windows, since it does not only use the wrong height, but also positions *all* menus on the primary monitor (even if the main window is on the secondary display). Please revert this change, we can't do it this way. But thanks for your efforts. The previous behavior was only a minor glitch that could probably be corrected as suggested by Ian, but this one is really bad. Sorry. :-( Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) Fl::x(), y(), w() and h() functions return this: - on Mac OS, the workarea size of the focus-containing screen - on MSWIN, the workarea size of the main screen - on X11, the workarea size of fl_screen The modification therefore makes large menus work well on Mac OS and X11 with multiple displays. Under MSWIN with multiple displays, it should work well for the main screen. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) Manolo, Yes, that works OK, *for the single-monitor* case - but as you will no doubt have noted from my analysis of the problem above, I am not certain that this will work in a multi-head case, where there may be multiple displays of differing sizes. In that case, IIRC, x(), y(), w() and h() return a bounding rectangle over all the screens (that certainly used to be the behaviour when I was testing multi-head systems way back when, it may no longer be the case...) whereas the menu code clearly needs to understand the bounds for the *current* screen only. I do not have access to a multi-head system at present to test this on, but my suspiscion is that the "fix" as implemented will NOT work at all well on a multi-head system. Indeed, I think we changed to using screen_xywh() specifically to cope with the multi-head case. (Though back then screen_xywh() returned work-area rather than screen-area, so that was OK!) Does anyone have a multi-head system we can verify this on? Also - I still like the suggestion that we try and add little "there is more" arrows to the large menus in this case (other UX factors of using large menus notwithstanding...!) Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) Can the OP report whether the regression is fixed with r.8929 ? It turns out that functions Fl::x(), Fl::y(), Fl::w() and Fl::h() return work-area data. Calling them in src/Fl_menu.cxx appears to fix the regression introduced at r.8724. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Fix Version: 1.3-current (r8929) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current Oops - meant to say: little arrows might be a nice addition. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current The idea of adding an optional flag to the the screen_xywh calls for WORK_AREA vs SCREEN_AREA is attractive - but there are (currently) 4 different forms of screen_xywh() so it might be tricky to add the extra flag and still have the compiler distinguish which versions we mean? That was why I suggested adding work_xywh() calls too (maybe all 4 cases?) - though I don't know how that would affect compatability... Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current I suggest that we add an optional flag to the the screen_xywh calls for WORK_AREA vs SCREEN_AREA. This will keep binary compatibility. If we add arrow or not is a second thought. I personally like the arrows, but not for clicking, rather for indicating that dragging the mouse there will do something. Clicking should work for menu items only. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current I've seen little up/down arrows (^ at the top, v at the bottom) in large menus of other applications, where you click those to scroll. By keeping the menu outside of the taskbar, perhaps that would be a welcome workaround. Perhaps too, we should allow the scroll wheel to scroll the menu. Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current OK, here's some more details. Albrecht and I have looked into this, and here's some notes... Consider fltk-1.3 r8914, in the file Fl_Menu.cxx at lines 282 and 416 we ascertain the current screen dimensions by doing: Fl::screen_xywh(scr_x, scr_y, scr_w, scr_h); Now, prior to STR #2640, that would return the *work area* of the screen in which the cursor was located. But that was not the documented behaviour for Fl::screen_xywh() - it was *supposed* to return the *screen size* instead. So #2640 fixed Fl::screen_xywh() to behave correctly. But the (unforseen) side effect is that the menu code now creates menus that extend to the screen edge, not to the limit of the user-accessible work area, and so menus may extend behind the taskbar / dock / whatever-icon-system-your-WM uses... The consequence of course is that the menu items that are "shown" behind the dock are not user accesible, and the auto-scrolling of large menus does not work, as the user can not "reach" the bottom of the menu. Previously, of course, this all worked OK because the menu was (by fortuitous error, it seems) reading the *work area* instead of the *screen size* and the menus were then bounded to user accessible space... So: how to fix this regression? Fl::w() and Fl::h() still return the *work area* so in a single-monitor setup that might work OK. I can't see how to get the *work area* of the current screen in a multi-head set up though, so we may well be stuck. Unless Fl::w() and Fl::h() do refer to the current screen? But I don't think they do, I'm pretty sure they return the "whole" work area over multiple screens - or at least, that's what I remember doing when we were running multi-head WinXP test sets here... Perhpas we need to consider adding a method analogous to Fl::screen_xywh(); maybe Fl::work_xywh() perhaps, to obtain the usable work area and limits of the current screen? That seems like it may be a useful facility anyway, and not just for use in Fl_Menu creation but as a general thing for users too... Thoughts? Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2695: huge menus do not scroll at screen edges any more - regression
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current At least on Windows, possibly others, the huge menus no longer scroll at screen edges. This can be seen by testing with the menubar demo. Compare with fltk-1.1.10 which seems to be OK. Albrecht has identified that this regression is related to svn rev. 8724 (STR #2640), which changed the way the bounds of the screen are computed. As a result, at least on Windows, the menu code does not start scrolling until the mouse reaches the very bottom of the screen, rather than at the bottom of the usable screen (i.e. above the task bar, if it is visible.) However, if the Windows task bar is visible, the mouse events are eaten by it rather than passed to fltk, so the menu never knows it needs to scroll. Or, at least, that's what I think is happening, anyway... Link: http://www.fltk.org/str.php?L2695 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
