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.
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).
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.
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.
Unfortunately without some fix however the system is pretty unusable
since no Java application will accept keyboard input.
Best,
--
Tim Howe
http://quadium.net/~vsync/
The lack of interest, the disdain for history is what makes computing
not-quite-a-field. [...] They have no idea where [their culture came
from] and the Internet was done so well that most people think of it
as a natural resource like the Pacific Ocean, rather than something
that was man-made. When was the last time a technology with a scale
like that was so error-free? The Web, in comparison, is a joke. The
Web was done by amateurs.
-- Alan Kay
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
