Advice to add new feature widgets

Feature request
1

I hope upstream can support new widgets as below:

Radio Buttons
Animated Digital Clock
Animated Analog Clock
Text Progress bar
Image Progress bar
Date text box
Repeat Button

2

It would be possible to have a group of radio buttons and make them mutually exclusive (only one selected at the time) or that should be up to the user?

3

I didn’t realize that there was already a forum post here - I had responded on GitHub with my thoughts.

4

I would like to help implement radio buttons, i need them for a project, any pointers on how to implement them?
I need them to be mutually exclusive, should that be done at widget or application level?

5

To keep the core library simple, I’d suggest doing it at the application level. You should probably have a set of enum values that decides which button is checked. You can use user_data on each checkbox to store its associated enum value. Then, in an LV_EVENT_VALUE_CHANGED handler, you should set the current value to be whatever the user_data of that checkbox is. Finally, loop through each of the checkboxes and call lv_checkbox_set_checked(cb, current_val == lv_obj_get_user_data(cb)).

Here’s some pseudo-code:

enum cb_vals {
    COMPRESSION_OFF,
    COMPRESSION_GZIP,
    COMPRESSION_LZMA,
     _NUM_COMPRESSION_VALS
};

enum cb_vals current_val = COMPRESSION_OFF;

lv_obj_t *radios[_NUM_COMPRESSION_VALS];

static void cb_handler(lv_obj_t * obj, lv_event_t event)
{
    if(event == LV_EVENT_VALUE_CHANGED) {
        current_val = lv_obj_get_user_data(obj);
        for(int i = 0; i < _NUM_COMPRESSION_VALS; i++) {
            lv_checkbox_set_checked(radios[i], current_val == lv_obj_get_user_data(radios[i]));
        }
    }
}

radios[0] = lv_checkbox_create(lv_scr_act(), NULL);
lv_checkbox_set_text(radios[0], "No compression");
lv_obj_set_user_data(radios[0], (lv_obj_user_data_t)COMPRESSION_OFF);
lv_obj_set_event_cb(radios[0], cb_handler);
radios[1] = lv_checkbox_create(lv_scr_act(), NULL);
lv_checkbox_set_text(radios[1], "ZIP compression");
lv_obj_set_user_data(radios[1], (lv_obj_user_data_t)COMPRESSION_ZIP);
lv_obj_set_event_cb(radios[1], cb_handler);
radios[2] = lv_checkbox_create(lv_scr_act(), NULL);
lv_checkbox_set_text(radios[2], "GZIP compression");
lv_obj_set_user_data(radios[2], (lv_obj_user_data_t)COMPRESSION_GZIP);
lv_obj_set_event_cb(radios[2], cb_handler);
1 Like
6

Radio buttons are ALWAYS mutually exclusive among their group only checkboxes are not. So I think it would be ok to do it at the widget level. It would also be more efficient and easier for others to implement. Radio buttons are also a standard form control.

Could create a radio group and have a variable for which one is checked instead of a true false value for each radio button. If you only have 1 radio button it is really a round check box. :smiley:

Like this would make it easy to call as well:
lv_create_radio(parent, values, checked);

7

Good real life example for discussion here. :slight_smile:

I’ll comment there about it to keep things in one place.

8

You’re right, in Qt radio buttons are mutually exclusive. Should we also have a “default” radio button selected?

9

I think yes, as exactly one option should be selected.

10

I’ve made radiobuttons for myself from lv_btnm, by slapping on an additional design_cb which draws the actual radiobuttons (simply as a rectangle round enough to be a circle… :slight_smile: ). Space for the radiobutton on button was added simply by expanding padding. lv_btnm has most of what you need, although the exclusivity handling needed a bit of a fix, as the original allows zero buttons be selected.

This said, I can’t share code, as I’m paid for writing it, and I also use a heavily modified v6.0 and am not interested in porting to v7.

Gabor,

IMO, for usability/success of lvgl, stability, hundreds of working examples and appropriate documentation (including tutorials/explanations to the examples) are much more important than any academic clean canonical set of widgets. My 2 eurocents.

Jan

11

In HTML radio buttons don’t have a default selected. I think you have more freedom without it but should have the option of setting it. If you have a default selected you need more validation as well. You can’t just check for null to see which sections of a form have been filled out or if that part is set to hidden or not needed since looping through your data you will encounter that value. At the very least you would need an if statement to see if that value has been changed. But if all empty form fields are null you only need to process the ones that are not null.

You can also get wrong submissions. Imagine a shopping cart where you select an option and the customer forgets to change it to the one they want. If you have non selected you catch that error. If you select some option you send them the wrong item or wrong power cable as an example.

I wouldn’t want to use btn matrix to make a hacked together radio button. The web started out like that and became a mess of hacks that is still being fixed now. It is better to add a Radio group widget. Since we have been talking about more modularity it will not bloat your code if you don’t use them and if you do use them it will be more efficient than any hacked together implementation using a checkbox or button matrix.

12

Well, don’t, I don’t care. I need things get done, don’t have time for theoreticizing. I can rewrite it to the same form as other widgets are, but what’s the point, it would just duplicate most of the lv_btnm.c’s content.

As I said, I don’t intend to contribute actual code; my point was only that IMO btnm (buttonmatrix) is a far better starting point for practical radiobuttons than checkbox. YMMV.

JW

13

I totally agree that checkbox is not the best option. If the button matrix works for you then use it. I am just trying to make the case that Radio groups are a part of the standard form controls and deserve their own widget. Obviously LV is still a work in progress and as features get created more options present themselves.