On Wed, Jun 17, 2015 at 05:21:36PM -0700 I heard the voice of Greg A. Woods, and lo! it spake thus: > > Anyway, what's happening is that some (not all) menus, e.g. the menu > I've defined for Button1 on the root window, will only appear in a > fixed location, and if the cursor isn't at the top-centre of that > location when you click, finding where to move the cursor to > activate menu selections is difficult/impossible (the active > location for menu entries is relative to where the menu should be, > but there's no visual feedback to know for sure you're over the > right entry).
#include <I_don't_really_know_the_menus_code.h> I don't really even have a good guess. I'm a little surprised at the no feedback; I'd offhand think (with no code investigation to back it up) that if the location were known enough that it'd activate the entry on release, it'd also be known to the highlighting, but maybe they're dissociated enough that that's silly. The code in question is apparently the PopUpMenu() func. If the menu were pinned, it doesn't hit paths that would move it, but then it'd always be visible too; that doesn't map it, just raises it. Otherwise it _should_ always move the window around to the coordinates specified by the caller. There's the particular CaptiveRoot-related case (menus.c:1741 in trunk) which is ever so slightly suspicious, but doesn't look obviously wrong. However, that'd be up on my list of suspicious things, since all the *Root stuff is a little weird, and sounds like something Xquartz might hit. So I'd drop a spike there and see if it's hitting that path. There's a call from in UpdateMenu() for popping up submenus. It might be an interesting diagnostic to see where submenus show up, whether it's relative to the cursor or relative to the parent menu. Especially if you can get the parent menu stuck, and _then_ try opening the submenu the first time. At least, it's data; I'm not immediately sure what either answer would mean, but... Otherwise, it seems to mostly get run via event processing, and is probably happening through do_menu, in which case it should always be getting the coordinates from the mouse event. So if I were to try tracking it down, I'd start by sticking a spoke in do_menu() to spit out the x/y coordinates it dredges up, and see if (a) that's in fact the path that's getting hit, and (b) what coordinates it's getting. If it's getting wacky numbers from there, well, that's your answer (though I'd expect all SORTS of things to be b0rked then, so I presume that's not it). If they're sensible, well, I'd wander down into PopUpMenu and figure out what's going on, probably starting with the CaptiveRoot bit mentioned above. > So, for now I've just been sticking to an older release, 3.5.2, > which does not exhibit this problem. (twm doesn't have this problem > either) A little VCS history poking suggests that the CaptiveRoot handling there came in between 3.6 and 3.7, so it's not impossible that has something to do with it. If you could test across that gap, that might give a hint as to whether that's where it came from. Or if you can do some testing on the current head, you might try pulling the XMoveWindow in menus.c:1746 out of the else and just making it unconditional. It seems like that fixing it would be weird, but... well, it's X, so... -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
