Feature #2423: add proper key-to-event mappings in GUI - User Interface - Golden Code Redmine

Feature #2423

add proper key-to-event mappings in GUI

Added by Constantin Asofiei over 9 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Constantin Asofiei

Target version:

FWD - GUI Support for a Complex ADM2 App

Start date:

06/08/2015

Due date:

% Done:

billable:

vendor_id:

GCD

gui.txt (53 KB) Constantin Asofiei, 10/23/2014 01:30 PM

chui-win.txt (59.4 KB) Constantin Asofiei, 10/23/2014 01:30 PM

chui-linux.txt (61.1 KB) Constantin Asofiei, 10/23/2014 01:30 PM

ca_upd20141029b.zip (203 KB) Constantin Asofiei, 10/29/2014 02:57 PM

ca_upd20141029c.zip (218 KB) Constantin Asofiei, 10/29/2014 03:49 PM

ca_upd20141030b.zip (220 KB) Constantin Asofiei, 10/30/2014 02:41 AM

ca_upd20141031a.zip (220 KB) Constantin Asofiei, 10/31/2014 05:25 AM

ca_upd20141105c.zip (221 KB) Constantin Asofiei, 11/05/2014 09:09 AM

Subtasks

Related issues

History

#1 Updated by Constantin Asofiei over 9 years ago

From #2252 note 391:

Greg Shah wrote:

I don't understand how is GUI mode special, so that it needs to treat the keyboard differently.

It isn't special. My only concern was to ensure that the GUI driver did in fact provide key events as required for widgets and READKEY.

OK, I think you are correct to be concerned, to some extent. Keys are read properly, but not all keys are interpreted the same way in GUI i.e.:
- in P2J, ALT-F4 doesn't show as the proper key code on my windows machine
- in 4GL, ESC is a replacement for what F4/END-ERROR does on ChUI
- in 4GL, F4 looks like it triggers CLOSE event
- in 4GL, F1 is linked to HELP and F2 is linked to GO event.

I think we should treat this in a separate task - we might need a way to make the Keyboard mappings configurable depending on the GUI/ChUI mode.

#2 Updated by Constantin Asofiei over 9 years ago

Status changed from New to WIP
Assignee set to Constantin Asofiei

#3 Updated by Constantin Asofiei over 9 years ago

Greg, for this task, beside adding the key functions in Keyboard$WorkArea, the SwingKeyboardReader needs to be split into ChUI and GUI implementations. Can you tell me what did you use as source for the original SwingKeyboardReader? Did you use the Programming Interfaces -> Handling User Input chapter or some other documentation?

#4 Updated by Greg Shah over 9 years ago

If I recall correctly, I started with a deep review of the 4GL docs and our current ChUI/NCURSES source code. I think I also used keys.p, keytest.p and key_code_report.p to review behavior of our current P2J implementation. At the time I did not have access to a 4GL dev system, so that is why some of the TODOs exist in the class. My objective was to get the swing ChUI client working like the NCURSES client for an interactive user.

#5 Updated by Constantin Asofiei over 9 years ago

File chui-linux.txt added
File gui.txt added
File chui-win.txt added

After running key_code_report.p (for keys 0 to 2048), the key labels/functions for ChUI in linux and windows are different - this explains the collisions I saw for the MIDDLE-MOUSE-* and MOUSE-MOVE-* event codes.

I think we need the following:

create Keyboard instances for each case - ChUI win/linux and GUI
at runtime, P2J will determine which keyboard to use depending on the client type (ChUI or GUI) and the OS compatibility set in the directory (windows/linux).

Another issue is that I think on Windows, ALT has the same usage as ESC under linux - all key labels with a ESC- have ALT- instead.

So, for the current GUI project, I will focus on having correct key mappings for GUI usage, but I will search if I can find a smart way of "pluging in" this into the driver.

#6 Updated by Greg Shah over 9 years ago

Interesting findings. This is just one more place where Progress didn't spend the effort to make the platforms appear (the the 4GL programmer) to be more consistent. I'm OK with your approach.

#7 Updated by Constantin Asofiei over 9 years ago

Another frustrating fact about events: although the WINDOW-* events are reporting LAST-EVENT:CODE values (other than -1), these values are not reported by the KEY-CODE("WINDOW-*") function: this always returns -1... Progress either uses different tables for PROGRESS and KEYPRESS events or something else is happening. The collisions are (for GUI WINDOW-* events):

WINDOW-CLOSE: 1078 - ALT-6
WINDOW-MAXIMIZED: 1094 - ALT-F
WINDOW-MINIMIZED: 1095 - ALT-G
WINDOW-RESTORED: 1096 - ALT-H
WINDOW-RESIZED: 1120 - ALT-`

#8 Updated by Constantin Asofiei over 9 years ago

File ca_upd20141029b.zip added

This is a implementation of keyboards compatible with ChUI (linux/windows) and GUI (windows). When working on GUI mode, is important to set the server/runtime/default/opsys/override to win32 (in directory.xml) and the client/chui/windows=true attribute in the client's bootstrap config.

Note that some refactoring was needed related to how the SwingKeyboardReader instance is used: because the client's compatibility mode (linux/windows) is required to be known BEFORE the client's session is established, all simulators require a SwingKeyboardInstance as parameter; it's the caller's responsibility to ensure that the same instance is shared by multiple simulators (i.e. in GUI mode, all windows will share the same instance). In ChUI mode, as only one window exists, is OK to pass a new instance directly.

Regression testing was not performed yet; will be done after the merge with the #2229 / ca_upd20141029a.zip update.

#9 Updated by Constantin Asofiei over 9 years ago

PS: the issue in note 7 is not yet fixed.

#10 Updated by Constantin Asofiei over 9 years ago

File ca_upd20141029c.zip added

This is replacement for 1029b.zip (merged with rev 10638) and is going into regression testing. Note 7 still applies.

#11 Updated by Constantin Asofiei over 9 years ago

File ca_upd20141030b.zip added

Fixed a regression and javadoc issues.

#12 Updated by Greg Shah over 9 years ago

Code Review ca_upd20141030b.zip

I'm good with the changes. It is a decent approach. The unavoidable 4GL nastiness makes the solution pretty tricky.

What do you suggest in regard to note 7?

#13 Updated by Constantin Asofiei over 9 years ago

Greg Shah wrote:

Code Review ca_upd20141030b.zip

I'm good with the changes. It is a decent approach. The unavoidable 4GL nastiness makes the solution pretty tricky.

What do you suggest in regard to note 7?

I suggest to defer it... it requires more analysis on how the PROGRESS/KEYPRESS events are managed by 4GL. My theory is that they are using different event tables, but I don't know yet how we can prove this.

On a side note, runtime testing is almost passed, need one more run to clear false negatives. But I think I will release this after Marius's work, so that he doesn't have to merge again.

#14 Updated by Greg Shah over 9 years ago

I suggest to defer it... it requires more analysis on how the PROGRESS/KEYPRESS events are managed by 4GL. My theory is that they are using different event tables, but I don't know yet how we can prove this.

OK. Please add a bug task referencing this task and note 7. Don't set a milestone, as I'm not sure this will impact us right now.

But I think I will release this after Marius's work, so that he doesn't have to merge again.

I appreciate your consideration here.

#15 Updated by Constantin Asofiei over 9 years ago

File ca_upd20141031a.zip added

This one is merged with mag_upd20141030b.zip from #2252. Testing passed, release is pending.

#16 Updated by Constantin Asofiei over 9 years ago

File ca_upd20141105c.zip added

This one fixes a regression related to keyboard (was not being re-initialized properly after a reset). Built on top of ca_upd20141105a.zip from #2252 (related to #2416).

One final regression testing (with ca_upd20141105a.zip) with is running.

#17 Updated by Constantin Asofiei over 9 years ago

ca_upd20141105c.zip was committed to bzr rev 10646.

#18 Updated by Greg Shah over 9 years ago

Status changed from WIP to Closed

#19 Updated by Constantin Asofiei over 9 years ago

In GUI, according to official manual, the CTRL-C equivalent is CTRL-BREAK. This has a key-code of 541, but pressing CTRL-BREAK in the windev01 emulator sends a CTRL-CTRL-S key (code 2067), which does raise a STOP condition. More, using the on-screen keyboard does not help - I've tried pressing CTRL-PAUSE, CTRL-Fn-PAUSE or other combinations (via the on-screen keyboard), but the CTRL-BREAK key was not emitted, nor STOP condition raised.

As a side note: pressing CTRL-C and restarting the client in GUI P2J is problematic. Currently, the windows are cleaned upon client restart in TC.initializePrep, but this should be done when the client is shutting down, after standardEntry API call is finished; if the window is still in a "responding" state when it needs to be cleared, events can be fired (like mouse or window activated) which can cause deadlocks. For know, I'll assume that CTRL-BREAK will have the same behaviour as CTRL-C.

#20 Updated by Constantin Asofiei over 9 years ago

More findings: on linux, the PAUSE/BREAK key emits the CTRL-S key (code 9). I think CTRL-BREAK (code 541) might be an event/function raised when pressing CTRL-CTRL-S... the weird part is that CTRL-S (code 9) is not raised when pressing PAUSE/BREAK, on the on-screen keyboard or directly; CTRL-PAUSE raises CTRL-CTRL-S...

We have two choices: either allow STOP condition to be raised by CTRL-CTRL-S (and maybe translate this into 541?) or assume that the documentation is wrong and in GUI CTRL-BREAK does not work... I'm inclined to believe the second part.

#21 Updated by Greg Shah over 9 years ago