LabRat Report post Posted June 4, 2007 There is a bug that manifests sometimes wherein if you click away from the EL window, the client receives the mousepress and acts on it. Hopefully the below patch may stop it, it seems to work for me: http://developer.berlios.de/patch/index.ph...p;group_id=1256 Let me know if it works for you or others please Share this post Link to post Share on other sites
ttlanhil Report post Posted June 4, 2007 a modified version of this (check in events.c instead of elwindows.c) is now in CVS, thanks Share this post Link to post Share on other sites
LabRat Report post Posted June 4, 2007 Great, that had bugged me for ages, but I didn't know the command, I was trying to see if SDL_lostfocus was anything to do with it but I couldn't find an example out there in cyberspace Share this post Link to post Share on other sites
Alia Report post Posted June 5, 2007 (edited) I'm glad that it helped you, but code that is in cvs now is rather confusing: if(event->button.x >= window_width || event->button.y >= window_height || (SDL_GetAppState() & !SDL_APPMOUSEFOCUS)) 1. Why we test only for >=, but do not test for < 0? (Edit: because it is Uint i think no problem here then) 2. SDL_GetAppState() & !SDL_APPMOUSEFOCUS is always false. I think you were going to type this: !(SDL_GetAppState() & SDL_APPMOUSEFOCUS) Edited June 5, 2007 by Alia Share this post Link to post Share on other sites
ttlanhil Report post Posted June 5, 2007 (edited) 1. Why we test only for >=, but do not test for < 0? (Edit: because it is Uint i think no problem here then)not just that it's Uint (which means, if it were negative, it'd be a really large positive number instead) but also because it's (AFAIK) a position in our window, not the entire computer screen (unless they're the same, i.e. fullscreen)2. SDL_GetAppState() & !SDL_APPMOUSEFOCUS is always false. I think you were going to type this:!(SDL_GetAppState() & SDL_APPMOUSEFOCUS) darn it, yes, good spotting (I guess it's theoretically possible to &-match an inverted value, but that'd be the case of "this is off, everything else on")I'll fix that in CVS now ed: I would like to point out one thing, however, the windowing system that sends mouse-click events to programs that don't have focus at the time is (to my mind) messed up. as far as I'm concerned, this is either a windows bug, or a windows-sdl bug; same as the other cases of shared keystrokes and all Edited June 5, 2007 by ttlanhil Share this post Link to post Share on other sites
Alia Report post Posted June 5, 2007 ed: I would like to point out one thing, however, the windowing system that sends mouse-click events to programs that don't have focus at the time is (to my mind) messed up. as far as I'm concerned, this is either a windows bug, or a windows-sdl bug; same as the other cases of shared keystrokes and all If you think it is only windows-sdl bug, maybe we should #ifdef those checks for windows only and look if linux people will report about unfocused keypresses and mouse clicks? Not for release of course, but in cvs. Share this post Link to post Share on other sites
ttlanhil Report post Posted June 5, 2007 IMO, the simpler the code, the better. it's not going to have an impact on performance, and we don't know for sure that it's windows only (my best guess is that it's a window manager issue. there may be some other funky window manager out there for *nix that does similar) Share this post Link to post Share on other sites
Grum Report post Posted June 7, 2007 (edited) 2. SDL_GetAppState() & !SDL_APPMOUSEFOCUS is always false. I think you were going to type this:!(SDL_GetAppState() & SDL_APPMOUSEFOCUS) darn it, yes, good spotting (I guess it's theoretically possible to &-match an inverted value, but that'd be the case of "this is off, everything else on") No, that'd be SDL_GetAppState() & ~SDL_APPMOUSEFOCUS The ! operator does a logical negation, not bitwise, so !(anything non-zero) = 0. ed: removed "will fix" comment in quote for clarity Edited June 7, 2007 by Grum Share this post Link to post Share on other sites
ttlanhil Report post Posted June 7, 2007 well, d'oh, that's what happens when I post about bitwise operations when I haven't read about them for a while (by chance, I did read about them later) so yeah, using the !, you'll always get (var & 0) (unless the define is for 0, ie NOTHING_WRONG in some cases) oh well, the correct (I hope ) code is in CVS anyway Share this post Link to post Share on other sites
bluap Report post Posted June 7, 2007 (edited) ed: I would like to point out one thing, however, the windowing system that sends mouse-click events to programs that don't have focus at the time is (to my mind) messed up. as far as I'm concerned, this is either a windows bug, or a windows-sdl bug; same as the other cases of shared keystrokes and all Since this change went into CVS I've started occasionally loosing mouse use in the client. I have now worked out how to reproduce the problem. I'm using debian etch with the gnome desktop and the metacity window manager. I have "Select windows when mouse moves over them" enabled in my gnome window preferences but I get the same problem if I turn it off. I run el in a window that occupies most of my screen. Here's how the problem can be reproduced. 1) Using the mouse, switch from EL to another applications that overlaps the EL window. 2) Make sure the mouse position is in the other application but also over the EL window underneath. 3) Use ALT-TAB to switch back to the EL client. The window focus goes back to EL (the title bar is highlighted), I can type text. However, no mouse button functions work. If I move the mouse outside the EL window and back in, all is well again. I have added some debug to see what is going on. The code described above is kicking in and ignoring the mouse events as SDL_GetAppState()=6, SDL_APPMOUSEFOCUS is not set. However, the EL window does have focus and has just received an SDL_VIDEOEXPOSE event which it ignores. The released version of the client does not show this problem. Admittedly, this may be a fault of my window manager but I thought it worth letting you know. Edit: Edited as I had not quite managed to reproduced 100% with my first method, now its 100%. Edit2: Clarified, it's mouse button function that don't work. Edited June 7, 2007 by bluap Share this post Link to post Share on other sites
ttlanhil Report post Posted June 7, 2007 meh... well, right now what we do is ask SDL if we have mouse focus... given the above, it sounds like either SDL or the window manager is giving bad info Share this post Link to post Share on other sites
jamincollins Report post Posted July 25, 2007 Since this change went into CVS I've started occasionally loosing mouse use in the client. I've been fighting with this too. Since I play with EL displayed in a window (non-fullscreen) I frequently have to move the mouse out of the client and back in to get it to actually take focus. So far, the problem only manifests with the EL client. Using bluap's steps I can reproduce this 100% of the time. Running: Debian Etch, with Openbox v3.2 as my window manager. Share this post Link to post Share on other sites
Placid Report post Posted July 25, 2007 Since this change went into CVS I've started occasionally loosing mouse use in the client. I've been fighting with this too. Since I play with EL displayed in a window (non-fullscreen) I frequently have to move the mouse out of the client and back in to get it to actually take focus. So far, the problem only manifests with the EL client. Using bluap's steps I can reproduce this 100% of the time. Running: Debian Etch, with Openbox v3.2 as my window manager. I've been getting this too! I thought it might be just me (drivers etc), but i'm glad i'm not the only one. Whenever I alt-tab out of the client (I run it in windowed mode), moving I have to hover over something outside EL (such as the XFCE taskbar) to gain mouse control in EL (funnily enough, I can still see the animated X when clicking to move, but no movement)... Share this post Link to post Share on other sites
ttlanhil Report post Posted July 26, 2007 This is, IMO, an SDL bug (and hardly the first issue in SDL we've encountered). I can't seem to reproduce the problem, so could someone test the following? Index: events.c =================================================================== RCS file: /cvsroot/elc/elc/events.c,v retrieving revision 1.141 diff -u -r1.141 events.c --- events.c 9 Jul 2007 15:11:05 -0000 1.141 +++ events.c 26 Jul 2007 05:06:53 -0000 @@ -117,7 +117,7 @@ case SDL_MOUSEBUTTONDOWN: case SDL_MOUSEBUTTONUP: // make sure the mouse button is our window, or else we ignore it - if(event->button.x >= window_width || event->button.y >= window_height || !(SDL_GetAppState() & SDL_APPMOUSEFOCUS)) + if(event->button.x >= window_width || event->button.y >= window_height || !((SDL_GetAppState() & SDL_APPMOUSEFOCUS)||(SDL_GetAppState() & SDL_APPINPUTFOCUS))) { break; } With this code, if we have the keyboard focus but not mouse focus (according to SDL) then we still allow it to go through, depending on the coords. This isn't really correct, but hopefully it'll fix this problem without causing others (allowing clicks outside the window to do stuff inside the window is the other side of the problem) Share this post Link to post Share on other sites
Grum Report post Posted July 26, 2007 I haven't tested this, but looking at it: doesn't this patch ignore all mouse events now when the window has keyboard focus? Share this post Link to post Share on other sites
ttlanhil Report post Posted July 26, 2007 I haven't tested this, but looking at it: doesn't this patch ignore all mouse events now when the window has keyboard focus?I think you missed where the parenthesis are; !(mouse or keyboard)Or was there something else I missed? Share this post Link to post Share on other sites
Grum Report post Posted July 26, 2007 Nope, you're right, i missed the extra set of parentheses. Sorry for raising a false alarm. Share this post Link to post Share on other sites
jamincollins Report post Posted July 26, 2007 (edited) This is, IMO, an SDL bug (and hardly the first issue in SDL we've encountered).I can't seem to reproduce the problem, so could someone test the following? I've made the listed change to my CVS checkout (updated moments ago) and will keep you posted. However, initial results are very promising. Edit: So far it appears to be working fine. There still appear to be some focus issues (sometimes the client window doesn't seem to get focus until I click somewhere inside it), but the situation is much improved. I would consider this change a very positive one. Edited July 27, 2007 by jamincollins Share this post Link to post Share on other sites
ttlanhil Report post Posted July 29, 2007 Well, since I haven't had any reports of it causing new problems, it's now in CVS. Hopefully it'll now be as good as we can get it Share this post Link to post Share on other sites
Placid Report post Posted July 30, 2007 Thanks, he bug seems to be fixed my end. Although i'm still having to press CTRL twice when trying to CTRL+CLICK (drop all) from the quickbar. Is this related? Share this post Link to post Share on other sites