Open GoogleCodeExporter opened 9 years ago
Eclipse is receiving the proper keycode in the associated event but it is also
receiving the state of modifier "keys," one of which is BUTTON1. Apparently,
most
applications take no note of this & simply accept the keycode. Eclipse does
this as
well save the seven keycodes mentioned. For these keycodes, Eclipse doesn`t do
anything with them.
So, one method to deal with it would be to modify the bindings of Eclipse but I
see
no way to bind Left + BUTTON1 with an action.
It is possible that the Eclipse maintainers (or the Linux/SWT maintainers at
least)
may consider this a bug on their behalf so it might be worth reporting this
issue to
them.
I had limited success with the attached patch but this particular solution
renders
the auto-repeat of pushed-down keys ineffective; thus it isn't a particularly
attractive solution. Some modification of it, however, may allow the keys to
work as
expected.
Original comment by sunshinekisses@gmail.com
on 1 Jan 2010 at 4:36
Attachments:
I've logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=298766 for the
inconsistent
behaviour in swt.
Regarding cellwriter, is it able to trigger the event such that it does not
include
the BUTTON1 modifier? It seems like if this app is a virtual keyboard then it
should
trigger OS events that exactly match what is being mimicked.
Original comment by grant_ga...@yahoo.ca
on 4 Jan 2010 at 4:19
First off, I'm neither the maintainer or original author; I just use it & would
love
to see it work better with Eclipse.
From what I can tell, there are 2 methods available to produce synthetic key
events:
1) XTestFakeKeyEvent(), and
2) XSendEvent().
CellWriter currently uses the XTestFakeKeyEvent() function which does not allow
modification of the state flag; it just sends the appropriate key event. One
thing
that I noted & found rather appealing about using this method is the auto-repeat
functionality stays intact; the window manager (I suppose) notes that a key is
pressed (via XTestFakeKeyEvent()) and, after a while, causes repeated
generation of
the key press with no assistance from the application that called
XTestFakeKeyEvent().
On the other hand, there is XSendEvent(), which does allow sending any state
flag one
wants. However, the auto repeat feature mentioned above no longer works. So for
this
method to be viable (I suppose as I am not the maintainer), CellWritter would
need to
implement its own auto-repeat which I'm certain is doable but does complicate
matters
somewhat.
The attached patch causes CellWriter to use XSendEvent() (albeit imperfectly at
the
moment) instead of XTestFakeKeyEvent(); the aforementioned 7 keys generated by
CellWriter work as expected in Eclipse aside from there being no auto repeat.
Original comment by sunshinekisses@gmail.com
on 5 Jan 2010 at 11:51
Attachments:
Original issue reported on code.google.com by
risu...@gmail.com
on 11 Sep 2009 at 9:49