Jump to content

Widget accelerators (shortcuts) require hard focus :(


photo

Recommended Posts

Hi, in 2.16.1, we can add accelerator to gui widgets (good!) but they are only called if the gui window has focus.

Example: we have a main window (3d viewport) and a gui window, detached. This gui has some widgets (buttons) with accelerator (eg.  KEY_SPACE to iterate between cameras), and we navigate in the 3D view with mouse and keyboard (WASD). If the user clicks (focus) the main 3D window, then the accelerator does not work any more :(

There should be a way to force an accelerator to have "application" scope, not window scope. Otherwise, we have to resort to the old "update() { check if key is pressed manually... }"

Sidenote: you moved to hardware positioned key mapping, which is sometimes good (WASD move), sometimes an absolute mess (Ctrl-Z, the M key, or symbols). Please think about a way to allow for accelerators or Input management to be either hardware positioned, or locale defined. The current state is pretty much too complex to be used efficiently and too error prone.

Thanks!

Link to comment

Hi Stephane,

Quote

we can add accelerator to gui widgets (good!) but they are only called if the gui window has focus.

Yes, that part of the API we didn't change, but I think that can be implemented in the future updates.

 

Quote

Sidenote: you moved to hardware positioned key mapping, which is sometimes good (WASD move), sometimes an absolute mess (Ctrl-Z, the M key, or symbols). Please think about a way to allow for accelerators or Input management to be either hardware positioned, or locale defined. The current state is pretty much too complex to be used efficiently and too error prone.

If you have some ideas - please let us know :) Moving to scan codes was an intended change, but as far as I know you still can use the Unicode key value from pressed key and write an additional application logic that will handle this case.

Thanks!

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

The current API is: void setCallbackAccel ( Gui::CALLBACK_INDEX callback, unsigned int key, int ctrl, int alt, int shift )

where unsigned int key is from Input::KEY_* values, which are scan codes.

I would suggest something like:

  • void addCallbackAccel ( Gui::CALLBACK_INDEX callback, unsigned int key, int ctrl, int alt, int shift ); // same as existing, but add instead of set
  • void addCallbackAccel ( Gui::CALLBACK_INDEX callback, const char* str, int ctrl, int alt, int shift ); // a "unicode" string, in addition to the key scan code

Out of curiosity, what was the rationale to move all input to scan code? Apart from WASD-like keys, which are very few?

Link to comment

The main goal is to simplify cross-language and cross-layout development to avoid situations where position-based hotkeys are not working at all or working on a different buttons. You probably met some applications in the past which are only working when you switch language from FR to EN, which is quite inconvenient if you also need to type some texts here as well.

Unfortunately this change results in some specific key remaps that you would need to keep in mind (Z Y for QWERTZ and A Q Z Y M for AZERTY) and use unicode-based input for them. Or prepare 2 or 3 presets that will have correct mappings for each popular layouts (which we plan to introduce in the next Editor update).

If you know that your application will be used only with a single layout you can simply use scan-codes. The only drawback here is that scan codes we used are fit QWERTY layout perfectly, so for "M" mapping you need to use ";" scan-code.

Thanks!

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
×
×
  • Create New...