XworkArea handler cont.
Lars, the attached patch to xforms' forms.c cures these two bugs in xforms
handling of key events.
o xforms should swallow null keyevents. They occur during composition of
multi-byte chars. The problem was reported and a solution proposed here:
o xforms should pass FL_KEYRELEASE events to the widgets. Currently they are
swallowed.
I find that holding down the 'a' key continuously results in this
lyx -dbg 524292 (workarea + key) output.
Ie each and every KEYPRESS event is followed by a KEYRELEASE event.
Work area event KEYPRESS
Key is `a' [97]
Keysym is `a' [97]
State is
Workarea Diff: 141800041
KeySym is a
action first set to [88]
action now set to [88]
Key [action=88][a]
Cannot decode: a
SelfInsert arg[`a']
Workarea event: KEYRELEASE
Work area event KEYPRESS
Key is `a' [97]
Keysym is `a' [97]
State is
Workarea Diff: 250
KeySym is a
action first set to [88]
action now set to [88]
Key [action=88][a]
Cannot decode: a
SelfInsert arg[`a']
Workarea event: KEYRELEASE
You said yesterday that you would use this information to take the hack at
the bottom of this letter out of the FL_KEYPRESS part of XWorkArea's
handler. My question to you is how do you propose using this new information?
I envisage replacing it with something like
handler() {
// This variable is used to block spurious keyboard input from multiple
// FL_KEYPRESS events that are not separated by an FL_KEYRELEASE
// event.
static bool input_acceptable = true;
switch (event) {
case FL_KEYPRESS:
if (!input_acceptable) break;
...
workAreaKeyPress(LyXKeySymPtr(xlk), x_key_state(ret_state));
input_acceptable = false;
break;
case FL_KEYRELEASE:
input_acceptable = true;
break;
}
}
Is that what you had in mind too? If so, wouldn't the most suitable place for
this be in xforms itself, in the switch handling the raw XEvents
(do_interaction_step)
case KeyPress:
...
case KeyRelease:
...
Let me know your thoughts on this. (Incidentally, is this a real problem or
an imaginary one? Ie, is this code really needed?)
Angus
Code to go:
static Time last_time_pressed;
static unsigned int last_key_pressed;
static unsigned int last_state_pressed;
lyxerr[Debug::KEY] Workarea Diff:
xke-time - last_time_pressed
endl;
if (xke-time - last_time_pressed 25 // Should be tunable?
ret_state == last_state_pressed
xke-keycode == last_key_pressed) {
lyxerr[Debug::KEY]
Workarea: Purging X events. endl;
if (XEventsQueued(fl_get_display(), QueuedAlready) 0)
waitForX(true);
// This purge make f.ex. scrolling stop immediately when
// releasing the PageDown button. The question is if
// this purging of XEvents can cause any harm...
// after some testing I can see no problems, but
// I'd like other reports too. (Lgb)
break;
}
last_time_pressed = xke-time;
last_key_pressed = xke-keycode;
last_state_pressed = ret_state;
--- xforms-1.0-release/lib/forms.c Tue Nov 19 21:06:43 2002
+++ xforms-1.0-release-modified/lib/./forms.c Tue Dec 10 09:58:44 2002
@@ -1218,7 +1218,8 @@
}
static void
-fl_keyboard(FL_FORM * form, int key, FL_Coord x, FL_Coord y, void *xev)
+fl_keyboard(int event,
+ FL_FORM * form, int key, FL_Coord x, FL_Coord y, void *xev)
{
FL_OBJECT *obj, *obj1, *special;
@@ -1239,7 +1240,7 @@
if (obj1 obj1 != special)
special = fl_mouseobj;
-if (form-focusobj)
+if (event == FL_KEYPRESS form-focusobj)
{
FL_OBJECT *focusobj = form-focusobj;
@@ -1294,11 +1295,11 @@
/* space is an exception for browser */
if ((key 255 || key == ' ') (special-wantkey FL_KEY_SPECIAL))
- fl_handle_object(special, FL_KEYBOARD, x, y, key, xev);
+ fl_handle_object(special, event, x, y, key, xev);
else if (key 255 (special-wantkey FL_KEY_NORMAL))
- fl_handle_object(special, FL_KEYBOARD, x, y, key, xev);
+ fl_handle_object(special, event, x, y, key, xev);
else if (special-wantkey == FL_KEY_ALL)
- fl_handle_object(special, FL_KEYBOARD, x, y, key, xev);
+ fl_handle_object(special, event, x, y, key, xev);
#if FL_DEBUG = ML_INFO
M_info(KeyBoard, (%d %d)pushing %d to %s\n, x, y, key, special-label);
@@ -1424,8 +1425,9 @@
fl_pushobj = NULL;
fl_handle_object(obj, FL_RELEASE, xx, yy, key, xev);
break;
-case FL_KEYBOARD: /* A key was pressed */
- fl_keyboard(form, key, xx, yy, xev);
+case FL_KEYPRESS: /* A key was pressed */
+case FL_KEYRELEASE: /* A key was released */
+
Re: XworkArea handler cont.
Angus Leeming [EMAIL PROTECTED] writes: | Lars, the attached patch to xforms' forms.c cures these two bugs in xforms | handling of key events. | o xforms should swallow null keyevents. They occur during composition of | multi-byte chars. The problem was reported and a solution proposed here: | o xforms should pass FL_KEYRELEASE events to the widgets. Currently they are | swallowed. | I find that holding down the 'a' key continuously results in this | lyx -dbg 524292 (workarea + key) output. | Ie each and every KEYPRESS event is followed by a KEYRELEASE event. Look at the time difference between the KEYRELEASE and KEYPRESS events. -- Lgb
Re: XworkArea handler cont.
Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 2:19 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Lars, the attached patch to xforms' forms.c cures these two bugs in | xforms handling of key events. | | o xforms should swallow null keyevents. They occur during composition of | multi-byte chars. The problem was reported and a solution proposed here: | | o xforms should pass FL_KEYRELEASE events to the widgets. Currently they | are swallowed. | | I find that holding down the 'a' key continuously results in this | lyx -dbg 524292 (workarea + key) output. | Ie each and every KEYPRESS event is followed by a KEYRELEASE event. Look at the time difference between the KEYRELEASE and KEYPRESS events. | Why? Ie, I don't understand what you're attempting to do with this code. Just do it KeyRelease event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d What we do not want is cursors, auto-repeat chars that just continue to go after the key has been released. so we use xsync for this. The problem is to know when to run this xsync, we want to loose as few xevents as possible. -- Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: Look at the time difference between the KEYRELEASE and KEYPRESS events. | | Why? Ie, I don't understand what you're attempting to do with this code. Just do it KeyRelease event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d What we do not want is cursors, auto-repeat chars that just continue to go after the key has been released. so we use xsync for this. The problem is to know when to run this xsync, we want to loose as few xevents as possible. Ok. Here I get a diff of about 40 between events. Now what. KeyPress event, serial 25, synthetic NO, window 0x681, root 0x3b, subw 0x0, time 149133444, (69,68), root:(821,88), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyRelease event, serial 25, synthetic NO, window 0x681, root 0x3b, subw 0x0, time 149133487, (69,68), root:(821,88), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d
Re: XworkArea handler cont.
Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: Look at the time difference between the KEYRELEASE and KEYPRESS events. | | Why? Ie, I don't understand what you're attempting to do with this code. Just do it KeyRelease event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d What we do not want is cursors, auto-repeat chars that just continue to go after the key has been released. so we use xsync for this. The problem is to know when to run this xsync, we want to loose as few xevents as possible. | Ok. Here I get a diff of about 40 between events. Now what. Note that I did not ask for the difference between Press and Release, but Release and Press... -- Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 3:01 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: Look at the time difference between the KEYRELEASE and KEYPRESS events. | | Why? Ie, I don't understand what you're attempting to do with this | code. Just do it KeyRelease event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d What we do not want is cursors, auto-repeat chars that just continue to go after the key has been released. so we use xsync for this. The problem is to know when to run this xsync, we want to loose as few xevents as possible. | | Ok. Here I get a diff of about 40 between events. Now what. Note that I did not ask for the difference between Press and Release, but Release and Press... Too subtle for me I'm afraid. KeyRelease event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyRelease event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d So adjacent Release and Press events have the same time stamp. Next step? Angus
Re: XworkArea handler cont.
Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 3:01 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: Look at the time difference between the KEYRELEASE and KEYPRESS events. | | Why? Ie, I don't understand what you're attempting to do with this | code. Just do it KeyRelease event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d KeyPress event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: d What we do not want is cursors, auto-repeat chars that just continue to go after the key has been released. so we use xsync for this. The problem is to know when to run this xsync, we want to loose as few xevents as possible. | | Ok. Here I get a diff of about 40 between events. Now what. Note that I did not ask for the difference between Press and Release, but Release and Press... | Too subtle for me I'm afraid. | KeyRelease event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: d | KeyPress event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: d | KeyRelease event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: d | KeyPress event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: d | So adjacent Release and Press events have the same time stamp. Next | step? this means that you are autorepeating. -- Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 3:26 pm, Lars Gullik Bjønnes wrote:
What we do not want is cursors, auto-repeat chars that just continue
to go after the key has been released. so we use xsync for this.
The problem is to know when to run this xsync, we want to loose as few
xevents as possible.
| So adjacent Release and Press events have the same time stamp. Next
| step?
this means that you are autorepeating.
Ok. I'm getting there. You want code like this:
handler() {
static Time time_released;
static unsigned int last_key_pressed;
static unsigned int last_state_pressed;
switch (event) {
case FL_KEYPRESS:
{
if (!ev) break;
XKeyEvent * xke = reinterpret_castXKeyEvent *(ev);
if (xke-time - time_released 25 // should perhaps be tunable
xke-state == last_state_pressed
xke-keycode == last_key_pressed) {
// purge events
if (XEventsQueued(fl_get_display(), QueuedAlready) 0)
waitForX(true);
break;
}
// Go on to handle the key press and dispatch it to workAreaKeyPress
...
break;
}
case FL_KEYRELEASE:
if (!ev) break;
time_released = ev-xkey.time;
last_key_pressed = ev-xkey.keycode;
last_state_pressed = ev-xkey.state;
break;
}
}
Am I there?
Angus
Re: XworkArea handler cont.
Angus Leeming [EMAIL PROTECTED] writes:
| On Tuesday 10 December 2002 3:26 pm, Lars Gullik Bjønnes wrote:
What we do not want is cursors, auto-repeat chars that just continue
to go after the key has been released. so we use xsync for this.
The problem is to know when to run this xsync, we want to loose as few
xevents as possible.
| So adjacent Release and Press events have the same time stamp. Next
| step?
this means that you are autorepeating.
| Ok. I'm getting there. You want code like this:
Sorry for leading you on a leash like that...
As we progressed I began feeling a bit queasy...it might not be som
clever after all.
..but yes, something similar to this was what I thought of.
| handler() {
| static Time time_released;
| static unsigned int last_key_pressed;
| static unsigned int last_state_pressed;
| switch (event) {
| case FL_KEYPRESS:
| {
| if (!ev) break;
| XKeyEvent * xke = reinterpret_castXKeyEvent *(ev);
| if (xke-time - time_released 25 // should perhaps be tunable
|xke-state == last_state_pressed
|xke-keycode == last_key_pressed) {
| // purge events
| if (XEventsQueued(fl_get_display(), QueuedAlready) 0)
| waitForX(true);
| break;
| }
| // Go on to handle the key press and dispatch it to workAreaKeyPress
| ...
| break;
| }
| case FL_KEYRELEASE:
| if (!ev) break;
| time_released = ev-xkey.time;
| last_key_pressed = ev-xkey.keycode;
| last_state_pressed = ev-xkey.state;
| break;
| }
| }
| Am I there?
| Angus
--
Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 4:18 pm, Lars Gullik Bjønnes wrote: | Ok. I'm getting there. You want code like this: Sorry for leading you on a leash like that... As we progressed I began feeling a bit queasy...it might not be som clever after all. ..but yes, something similar to this was what I thought of. Don't worry. I sort of fit in these investigations around other stuff. Now I understand the requirements it's time for the big, philosophical qusetion. Where should this stuff go. In our XWorkArea widget or in the main xforms XEvent handler.? Ie, can you envisage ANY situations where one might want to pass auto-repeat events to the widgets? Regards, Angus
Re: XworkArea handler cont.
On Tuesday 10 December 2002 16:34, Angus Leeming wrote: Ie, can you envisage ANY situations where one might want to pass auto-repeat events to the widgets? When Lars finally commit his insetgame that he has in one of the other trees we develops. (?) ;-) That would be uber cool. ::-) Regards, Angus PS: Please, don't take me serious Lars. ;-) -- José Abílio
Re: XworkArea handler cont.
Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 4:18 pm, Lars Gullik Bjønnes wrote: | Ok. I'm getting there. You want code like this: Sorry for leading you on a leash like that... As we progressed I began feeling a bit queasy...it might not be som clever after all. ..but yes, something similar to this was what I thought of. | Don't worry. I sort of fit in these investigations around other stuff. | Now I understand the requirements it's time for the big, philosophical | qusetion. Where should this stuff go. In our XWorkArea widget or in the main | xforms XEvent handler.? Ie, can you envisage ANY situations where one might | want to pass auto-repeat events to the widgets? Certainly when I want to insert 1500 'd's. (Why would I want that? Not your business!) What we want to discover somehow is when the user release the key, with a lot of outstanding events... then we want to throw those events away. -- Lgb
Re: XworkArea handler cont.
José Matos [EMAIL PROTECTED] writes: | On Tuesday 10 December 2002 16:34, Angus Leeming wrote: Ie, can you envisage ANY situations where one might want to pass auto-repeat events to the widgets? | When Lars finally commit his insetgame that he has in one of the | other trees we develops. (?) ;-) M... meat... a small deer perhaps. (or a tiny rabbit) | PS: Please, don't take me serious Lars. ;-) Never, ever. -- Lgb
XworkArea handler cont.
Lars, the attached patch to xforms' forms.c cures these two bugs in xforms
handling of key events.
o xforms should swallow null keyevents. They occur during composition of
multi-byte chars. The problem was reported and a solution proposed here:
o xforms should pass FL_KEYRELEASE events to the widgets. Currently they are
swallowed.
I find that holding down the 'a' key continuously results in this
lyx -dbg 524292 (workarea + key) output.
Ie each and every KEYPRESS event is followed by a KEYRELEASE event.
Work area event KEYPRESS
Key is `a' [97]
Keysym is `a' [97]
State is
Workarea Diff: 141800041
KeySym is a
action first set to [88]
action now set to [88]
Key [action=88][a]
Cannot decode: a
SelfInsert arg[`a']
Workarea event: KEYRELEASE
Work area event KEYPRESS
Key is `a' [97]
Keysym is `a' [97]
State is
Workarea Diff: 250
KeySym is a
action first set to [88]
action now set to [88]
Key [action=88][a]
Cannot decode: a
SelfInsert arg[`a']
Workarea event: KEYRELEASE
You said yesterday that you would use this information to take the hack at
the bottom of this letter out of the FL_KEYPRESS part of XWorkArea's
handler. My question to you is how do you propose using this new information?
I envisage replacing it with something like
handler() {
// This variable is used to block spurious keyboard input from multiple
// FL_KEYPRESS events that are not separated by an FL_KEYRELEASE
// event.
static bool input_acceptable = true;
switch (event) {
case FL_KEYPRESS:
if (!input_acceptable) break;
...
workAreaKeyPress(LyXKeySymPtr(xlk), x_key_state(ret_state));
input_acceptable = false;
break;
case FL_KEYRELEASE:
input_acceptable = true;
break;
}
}
Is that what you had in mind too? If so, wouldn't the most suitable place for
this be in xforms itself, in the switch handling the raw XEvents
(do_interaction_step)
case KeyPress:
...
case KeyRelease:
...
Let me know your thoughts on this. (Incidentally, is this a real problem or
an imaginary one? Ie, is this code really needed?)
Angus
Code to go:
static Time last_time_pressed;
static unsigned int last_key_pressed;
static unsigned int last_state_pressed;
lyxerr[Debug::KEY] << "Workarea Diff: "
<< xke->time - last_time_pressed
<< endl;
if (xke->time - last_time_pressed < 25 // Should be tunable?
&& ret_state == last_state_pressed
&& xke->keycode == last_key_pressed) {
lyxerr[Debug::KEY]
<< "Workarea: Purging X events." << endl;
if (XEventsQueued(fl_get_display(), QueuedAlready) > 0)
waitForX(true);
// This purge make f.ex. scrolling stop immediately when
// releasing the PageDown button. The question is if
// this purging of XEvents can cause any harm...
// after some testing I can see no problems, but
// I'd like other reports too. (Lgb)
break;
}
last_time_pressed = xke->time;
last_key_pressed = xke->keycode;
last_state_pressed = ret_state;
--- xforms-1.0-release/lib/forms.c Tue Nov 19 21:06:43 2002
+++ xforms-1.0-release-modified/lib/./forms.c Tue Dec 10 09:58:44 2002
@@ -1218,7 +1218,8 @@
}
static void
-fl_keyboard(FL_FORM * form, int key, FL_Coord x, FL_Coord y, void *xev)
+fl_keyboard(int event,
+ FL_FORM * form, int key, FL_Coord x, FL_Coord y, void *xev)
{
FL_OBJECT *obj, *obj1, *special;
@@ -1239,7 +1240,7 @@
if (obj1 && obj1 != special)
special = fl_mouseobj;
-if (form->focusobj)
+if (event == FL_KEYPRESS && form->focusobj)
{
FL_OBJECT *focusobj = form->focusobj;
@@ -1294,11 +1295,11 @@
/* space is an exception for browser */
if ((key > 255 || key == ' ') && (special->wantkey & FL_KEY_SPECIAL))
- fl_handle_object(special, FL_KEYBOARD, x, y, key, xev);
+ fl_handle_object(special, event, x, y, key, xev);
else if (key < 255 && (special->wantkey & FL_KEY_NORMAL))
- fl_handle_object(special, FL_KEYBOARD, x, y, key, xev);
+ fl_handle_object(special, event, x, y, key, xev);
else if (special->wantkey == FL_KEY_ALL)
- fl_handle_object(special, FL_KEYBOARD, x, y, key, xev);
+ fl_handle_object(special, event, x, y, key, xev);
#if FL_DEBUG >= ML_INFO
M_info("KeyBoard", "(%d %d)pushing %d to %s\n", x, y, key, special->label);
@@ -1424,8 +1425,9 @@
fl_pushobj = NULL;
fl_handle_object(obj, FL_RELEASE, xx, yy, key, xev);
break;
-case FL_KEYBOARD: /* A key was pressed */
- fl_keyboard(form, key, xx, yy, xev);
+case FL_KEYPRESS: /* A key was pressed */
+case
Re: XworkArea handler cont.
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars, the attached patch to xforms' forms.c cures these two bugs in xforms | handling of key events. > | o xforms should swallow null keyevents. They occur during composition of | multi-byte chars. The problem was reported and a solution proposed here: > | o xforms should pass FL_KEYRELEASE events to the widgets. Currently they are | swallowed. > | I find that holding down the 'a' key continuously results in this | lyx -dbg 524292 (workarea + key) output. | Ie each and every KEYPRESS event is followed by a KEYRELEASE event. Look at the time difference between the KEYRELEASE and KEYPRESS events. -- Lgb
Re: XworkArea handler cont.
Angus Leeming <[EMAIL PROTECTED]> writes: | On Tuesday 10 December 2002 2:19 pm, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: >> | Lars, the attached patch to xforms' forms.c cures these two bugs in >> | xforms handling of key events. >> | >> | o xforms should swallow null keyevents. They occur during composition of >> | multi-byte chars. The problem was reported and a solution proposed here: >> | >> | o xforms should pass FL_KEYRELEASE events to the widgets. Currently they >> | are swallowed. >> | >> | I find that holding down the 'a' key continuously results in this >> | lyx -dbg 524292 (workarea + key) output. >> | Ie each and every KEYPRESS event is followed by a KEYRELEASE event. >> >> Look at the time difference between the KEYRELEASE and KEYPRESS >> events. > | Why? Ie, I don't understand what you're attempting to do with this code. Just do it KeyRelease event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" KeyPress event, serial 27, synthetic NO, window 0x4a1, root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" What we do not want is cursors, auto-repeat chars that just continue to go after the key has been released. so we use xsync for this. The problem is to know when to run this xsync, we want to loose as few xevents as possible. -- Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: > >> Look at the time difference between the KEYRELEASE and KEYPRESS > >> events. > | > | Why? Ie, I don't understand what you're attempting to do with this code. > > Just do it > > KeyRelease event, serial 27, synthetic NO, window 0x4a1, > root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), > state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, > XLookupString gives 1 characters: "d" > > KeyPress event, serial 27, synthetic NO, window 0x4a1, > root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), > state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, > XLookupString gives 1 characters: "d" > > What we do not want is cursors, auto-repeat chars that just continue > to go after the key has been released. so we use xsync for this. > The problem is to know when to run this xsync, we want to loose as few > xevents as possible. Ok. Here I get a diff of about 40 between events. Now what. KeyPress event, serial 25, synthetic NO, window 0x681, root 0x3b, subw 0x0, time 149133444, (69,68), root:(821,88), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" KeyRelease event, serial 25, synthetic NO, window 0x681, root 0x3b, subw 0x0, time 149133487, (69,68), root:(821,88), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d"
Re: XworkArea handler cont.
Angus Leeming <[EMAIL PROTECTED]> writes: | On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: >> >> Look at the time difference between the KEYRELEASE and KEYPRESS >> >> events. >> | >> | Why? Ie, I don't understand what you're attempting to do with this code. >> >> Just do it >> >> KeyRelease event, serial 27, synthetic NO, window 0x4a1, >> root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), >> state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, >> XLookupString gives 1 characters: "d" >> >> KeyPress event, serial 27, synthetic NO, window 0x4a1, >> root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), >> state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, >> XLookupString gives 1 characters: "d" >> >> What we do not want is cursors, auto-repeat chars that just continue >> to go after the key has been released. so we use xsync for this. >> The problem is to know when to run this xsync, we want to loose as few >> xevents as possible. > | Ok. Here I get a diff of about 40 between events. Now what. Note that I did not ask for the difference between Press and Release, but Release and Press... -- Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 3:01 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: > >> >> Look at the time difference between the KEYRELEASE and KEYPRESS > >> >> events. > >> | > >> | Why? Ie, I don't understand what you're attempting to do with this > >> | code. > >> > >> Just do it > >> > >> KeyRelease event, serial 27, synthetic NO, window 0x4a1, > >> root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), > >> state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, > >> XLookupString gives 1 characters: "d" > >> > >> KeyPress event, serial 27, synthetic NO, window 0x4a1, > >> root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), > >> state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, > >> XLookupString gives 1 characters: "d" > >> > >> What we do not want is cursors, auto-repeat chars that just continue > >> to go after the key has been released. so we use xsync for this. > >> The problem is to know when to run this xsync, we want to loose as few > >> xevents as possible. > | > | Ok. Here I get a diff of about 40 between events. Now what. > > Note that I did not ask for the difference between Press and Release, > but Release and Press... Too subtle for me I'm afraid. KeyRelease event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" KeyPress event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" KeyRelease event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" KeyPress event, serial 25, synthetic NO, window 0x601, root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, XLookupString gives 1 characters: "d" So adjacent Release and Press events have the same time stamp. Next step? Angus
Re: XworkArea handler cont.
Angus Leeming <[EMAIL PROTECTED]> writes: | On Tuesday 10 December 2002 3:01 pm, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: >> | On Tuesday 10 December 2002 2:29 pm, Lars Gullik Bjønnes wrote: >> >> >> Look at the time difference between the KEYRELEASE and KEYPRESS >> >> >> events. >> >> | >> >> | Why? Ie, I don't understand what you're attempting to do with this >> >> | code. >> >> >> >> Just do it >> >> >> >> KeyRelease event, serial 27, synthetic NO, window 0x4a1, >> >> root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), >> >> state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, >> >> XLookupString gives 1 characters: "d" >> >> >> >> KeyPress event, serial 27, synthetic NO, window 0x4a1, >> >> root 0x3a, subw 0x4a2, time 148348763, (52,23), root:(721,1037), >> >> state 0x0, keycode 40 (keysym 0x64, d), same_screen YES, >> >> XLookupString gives 1 characters: "d" >> >> >> >> What we do not want is cursors, auto-repeat chars that just continue >> >> to go after the key has been released. so we use xsync for this. >> >> The problem is to know when to run this xsync, we want to loose as few >> >> xevents as possible. >> | >> | Ok. Here I get a diff of about 40 between events. Now what. >> >> Note that I did not ask for the difference between Press and Release, >> but Release and Press... > | Too subtle for me I'm afraid. > | KeyRelease event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: "d" > | KeyPress event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024603, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: "d" > | KeyRelease event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: "d" > | KeyPress event, serial 25, synthetic NO, window 0x601, | root 0x3b, subw 0x0, time 152024653, (67,72), root:(1058,234), | state 0x0, keycode 35 (keysym 0x64, d), same_screen YES, | XLookupString gives 1 characters: "d" > | So adjacent Release and Press events have the same time stamp. Next | step? this means that you are autorepeating. -- Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 3:26 pm, Lars Gullik Bjønnes wrote:
> What we do not want is cursors, auto-repeat chars that just continue
> to go after the key has been released. so we use xsync for this.
> The problem is to know when to run this xsync, we want to loose as few
> xevents as possible.
> | So adjacent Release and Press events have the same time stamp. Next
> | step?
> this means that you are autorepeating.
Ok. I'm getting there. You want code like this:
handler() {
static Time time_released;
static unsigned int last_key_pressed;
static unsigned int last_state_pressed;
switch (event) {
case FL_KEYPRESS:
{
if (!ev) break;
XKeyEvent * xke = reinterpret_cast(ev);
if (xke->time - time_released < 25 // should perhaps be tunable
&& xke->state == last_state_pressed
&& xke->keycode == last_key_pressed) {
// purge events
if (XEventsQueued(fl_get_display(), QueuedAlready) > 0)
waitForX(true);
break;
}
// Go on to handle the key press and dispatch it to workAreaKeyPress
...
break;
}
case FL_KEYRELEASE:
if (!ev) break;
time_released = ev->xkey.time;
last_key_pressed = ev->xkey.keycode;
last_state_pressed = ev->xkey.state;
break;
}
}
Am I there?
Angus
Re: XworkArea handler cont.
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Tuesday 10 December 2002 3:26 pm, Lars Gullik Bjønnes wrote:
>> What we do not want is cursors, auto-repeat chars that just continue
>> to go after the key has been released. so we use xsync for this.
>> The problem is to know when to run this xsync, we want to loose as few
>> xevents as possible.
>> | So adjacent Release and Press events have the same time stamp. Next
>> | step?
>> this means that you are autorepeating.
>
| Ok. I'm getting there. You want code like this:
Sorry for leading you on a leash like that...
As we progressed I began feeling a bit queasy...it might not be som
clever after all.
..but yes, something similar to this was what I thought of.
| handler() {
| static Time time_released;
| static unsigned int last_key_pressed;
| static unsigned int last_state_pressed;
>
| switch (event) {
| case FL_KEYPRESS:
| {
| if (!ev) break;
| XKeyEvent * xke = reinterpret_cast(ev);
>
| if (xke->time - time_released < 25 // should perhaps be tunable
| && xke->state == last_state_pressed
| && xke->keycode == last_key_pressed) {
| // purge events
| if (XEventsQueued(fl_get_display(), QueuedAlready) > 0)
| waitForX(true);
| break;
| }
>
| // Go on to handle the key press and dispatch it to workAreaKeyPress
| ...
| break;
| }
| case FL_KEYRELEASE:
| if (!ev) break;
| time_released = ev->xkey.time;
| last_key_pressed = ev->xkey.keycode;
| last_state_pressed = ev->xkey.state;
| break;
| }
| }
>
| Am I there?
| Angus
>
--
Lgb
Re: XworkArea handler cont.
On Tuesday 10 December 2002 4:18 pm, Lars Gullik Bjønnes wrote: > | Ok. I'm getting there. You want code like this: > > Sorry for leading you on a leash like that... > > As we progressed I began feeling a bit queasy...it might not be som > clever after all. > > ..but yes, something similar to this was what I thought of. Don't worry. I sort of fit in these investigations around other stuff. Now I understand the requirements it's time for the big, philosophical qusetion. Where should this stuff go. In our XWorkArea widget or in the main xforms XEvent handler.? Ie, can you envisage ANY situations where one might want to pass auto-repeat events to the widgets? Regards, Angus
Re: XworkArea handler cont.
On Tuesday 10 December 2002 16:34, Angus Leeming wrote: > Ie, can you envisage ANY situations where one > might want to pass auto-repeat events to the widgets? When Lars finally commit his insetgame that he has in one of the other trees we develops. (?) ;-) That would be uber cool. ::-) > Regards, > Angus PS: Please, don't take me serious Lars. ;-) -- José Abílio
Re: XworkArea handler cont.
Angus Leeming <[EMAIL PROTECTED]> writes: | On Tuesday 10 December 2002 4:18 pm, Lars Gullik Bjønnes wrote: >> | Ok. I'm getting there. You want code like this: >> >> Sorry for leading you on a leash like that... >> >> As we progressed I began feeling a bit queasy...it might not be som >> clever after all. >> >> ..but yes, something similar to this was what I thought of. > | Don't worry. I sort of fit in these investigations around other stuff. > | Now I understand the requirements it's time for the big, philosophical | qusetion. Where should this stuff go. In our XWorkArea widget or in the main | xforms XEvent handler.? Ie, can you envisage ANY situations where one might | want to pass auto-repeat events to the widgets? Certainly when I want to insert 1500 'd's. (Why would I want that? Not your business!) What we want to discover somehow is when the user release the key, with a lot of outstanding events... then we want to throw those events away. -- Lgb
Re: XworkArea handler cont.
José Matos <[EMAIL PROTECTED]> writes: | On Tuesday 10 December 2002 16:34, Angus Leeming wrote: >> Ie, can you envisage ANY situations where one >> might want to pass auto-repeat events to the widgets? > | When Lars finally commit his insetgame that he has in one of the | other trees we develops. (?) ;-) M... meat... a small deer perhaps. (or a tiny rabbit) | PS: Please, don't take me serious Lars. ;-) Never, ever. -- Lgb
