Add a keyboard mode option for Upper Case

Hi @kisvegabor & @embeddedt ,

Is it possible to add a keyboard mode option to the current V6.0 release please? I have a requirement to change the keyboard to the upper case map on entry to a particular text box, which I have currently achieved by copying the uc_map/uc_ctrl_map from the lv_kb.c to my local .c file and resetting the keyboard map on entry to the text box. This works fine but I now have two copies of the keyboard maps floating around in the application which seems unnecessary as I don’t have a need to change the default maps.

I propose that the enum in lv_kb.h be redefined as follows:

    enum {
        LV_KB_MODE_TEXT,
        LV_KB_MODE_NUM,
        LV_KB_MODE_TEXT_UC,
    };
    typedef uint8_t lv_kb_mode_t;

Also the function lv_kb_set_mode() in kb.c is reworked as follows:

/**
 * Set a new a mode (text or number map)
 * @param kb pointer to a Keyboard object
 * @param mode the mode from 'lv_kb_mode_t'
 */
void lv_kb_set_mode(lv_obj_t * kb, lv_kb_mode_t mode)
{
    lv_kb_ext_t * ext = lv_obj_get_ext_attr(kb);
    if(ext->mode == mode) return;

    ext->mode = mode;
    if(mode == LV_KB_MODE_TEXT) {
        lv_btnm_set_map(kb, kb_map_lc);
        lv_btnm_set_ctrl_map(kb, kb_ctrl_lc_map);
    } else if(mode == LV_KB_MODE_NUM) {
        lv_btnm_set_map(kb, kb_map_num);
        lv_btnm_set_ctrl_map(kb, kb_ctrl_num_map);
    } else if(mode == LV_KB_MODE_TEXT_UC) {
        lv_btnm_set_map(kb, kb_map_uc);
        lv_btnm_set_ctrl_map(kb, kb_ctrl_uc_map);
    }        
}

What do you think?

Kind Regards,

Pete

It can be added to the dev-6.1 branch. Can you send a pull request?

Okay thank you very much, I have very recently gotten the simulator running on my Windows 10 laptop but still haven’t had chance to sort out the Git-Hub integration in Eclipse. I will take another look at it and attempt to do a pull request if I can get it working… I’ll let you know how I get on.

Cheers,

Pete

I am trying to remap the keys, but lv_kb_set_map() and lv_kb_set_ctrl_map() are not that useful because the maps are overwritten in lv_kb_def_event_cb() once the user changes keyboard shift states.

It would be better if lv_kb.c kept a pointer to the maps and then replaced the pointer with the user maps.

lv_kb.h

enum {
	LC_KB_SHIFT_LOWER,
	LC_KB_SHIFT_UPPER,
	LC_KB_SHIFT_SYMBOL,
};
typedef uint8_t lv_kb_shift_t;
...
void lv_kb_set_map(lv_obj_t * kb, lv_kb_shift_t shift, const char * map[]);
...
void lv_kb_set_ctrl_map(lv_obj_t * kb, lv_kb_shift_t shift, const lv_btnm_ctrl_t ctrl_map[]);

lv_kb.c

static const char * * kb_map[3] = { default_kb_map_lc, default_kb_map_uc, default_kb_map_spec };
static const lv_btnm_ctrl_t * kb_ctrl[3] = { default_kb_ctrl_lc_map, default_kb_ctrl_uc_map, default_kb_ctrl_spec_map };
...
lv_btnm_set_map(kb, kb_map[LC_KB_SHIFT_LOWER]);
...
void lv_kb_set_map(lv_obj_t * kb, lv_kb_shift_t shift, const char * map[])
{
	kb_map[shift] = map;
	lv_btnm_set_map(kb, map);
}

void lv_kb_set_ctrl_map(lv_obj_t * kb, lv_kb_shift_t shift, const lv_btnm_ctrl_t ctrl_map[])
{
	kb_ctrl[shift] = ctrl_map;
	lv_btnm_set_ctrl_map(kb, ctrl_map);
}

I’ve left out some items but I’m sure you get the idea. There are problems with the code - the maps are not stored in RO memory and the lv_kb_set_map functions set the maps without regard as to what map is currently in use (since there is no variable record of the shift state).

Now the next problem is that the keys to switch between maps is hard coded to ABC abc and 1#

@xennex
It sounds reasonable.
As we already have lv_kb_set_map it would be an API breaking update therefore it can go only to the next major release. Anyway can you open a Pull request on GitHub? We will merge it when dev-7.0 is created.

Ok. I really want the maps to be in flash rather than ram so the definitions are going to be

static const char * const default_kb_map_lc[] = ...
static const char * * kb_map[3] = { (const char * *)default_kb_map_lc, ...

rather than

static const char * default_kb_map_lc[]

which then causes some casting later. You can decide what is best when you merge.

@xennex
Okay.

Thank you for the PR. Let’s continue on GitHub.