On Mon, 01 Apr 2013 21:36:58 +0200, Tim Howe <vs...@quadium.net> wrote:
> Kim Woelders wrote: > >> On Mon, 01 Apr 2013 11:36:17 +0200, Tim Howe <vsync@...> wrote: >> >>> This is relevant to graphical Java applications which require it. >> >> Is this the same thing as >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009224 ? > > Heh, it seems to be although I didn't find that bug until after I had > filed my own (which I can't now find); Sun's bug tracker really went > downhill after the Oracle acquisition. It's also related to this bug > which is what sent me in the right direction: > > http://bugs.sun.com/view_bug.do?bug_id=6798064 > >> I'm not convinced there actually is a problem here at the e16 end >> (except that the WM gets the blame anyway), and it looks like the >> current problem with java applications was introduced by a change in >> jdk7. > > It's definitely triggered by a change in Java which is why I filed my > own bug; while it might be correct it'd be ideal to avoid regressions. > However, from what I can tell it unfortunately is related to a bug in > e16. Of the 4 input models specified in ICCCM 4.1.7 it only supports 3 > (possibly 2): No Input, Passive, and Locally Active but with a twist. > >> I'll poke around a bit and try to figure out what goes on here. > > I can save you a little time and give you a quick tour :) For reference > I've posted a copy of the patch since I think my original post's stuck > in moderation: http://quadium.net/code/e16.focus.globally-active.patch > > So in Globally Active mode the WM should never call XSetInputFocus on > the target window but rather only send WM_TAKE_FOCUS. Therefore the > first thing I did was edit ICCCM_GetWmProtocols() so that the > WM_TAKE_FOCUS property doesn't force the input hint on (I believe > this was conflating Locally Active with Globally Active). > > Then I added a check in ICCCM_Focus() to ensure it only calls > XSetInputFocus() in case where the input field is genuinely set. > > Finally I had to tweak how inhibit_focus got set in EwinStateUpdate() or > Globally Active windows would be treated the same as No Input. Probably > that's the original reason for the input flag munging mentioned above. > Ok, so far I'm fine with the changes, and I have committed them. Seems to work just fine here - I also have a few java thingies that have been annoying me for a while. > Now at this point e16 is setting the focus in the right circumstance. > But its internal state and UI might not match the real world of the X > server, since the WM_TAKE_FOCUS protocol allows the client to set input > focus to any of its windows once offered. So that's the reason for the > rest of the changes, to wait to set focus on the target window until it > accepts it (or to change focus if the client redirects focus in the > "Locally Active" model). > Yeah, basically it is assumed that the client we want to focus with ICCCM_Focus() also gets the focus, and does not lose it because some other client steals it. So in principle the window decoration can become wrong in any of the focus modes. I don't ever see it happen though, so I haven't bothered to fix it properly. If fixing it, I think it should be done globally for all focus modes. > I thought about splitting the focus code into 2 parts, one which > determines where to send focus and the other which listens to focus > events from the X server and only then updates decorations etc. That would probably be the proper thing to do. > However as you said it's a sensitive area so I set it up for the logic > flow to only change in the case of Globally Active windows, which > weren't working anyway. Hence the need for the FOCUS_SERVER value, so > server focus notifies can be treated completely separately from > FOCUS_SET or anything like that. > > If you have any other questions or concerns please let me know. As a > heads-up I did happen to discover a minor cosmetic issue which only > appears when this patch is applied (whether the patch causes or merely > triggers it I'm not sure yet) and only occurs in compositing mode when a > menu is triggered then reverted and the client with focus has an active > modal dialog. If you'd like to hold this patch until it can be > superseded or a companion patch supplied I totally understand. > I would be surprised if there wasn't a glitch here and there. Fortunately I hardly ever notice one :) > Unfortunately without some fix however the system is pretty unusable > since no Java application will accept keyboard input. > > Best, Thanks, /Kim ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
