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 [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
