Set multiple paddings / margins at once

[peejii73]

Hello.

I have noticed I often run into a situation where I have to adjust either all four paddings (or margins) of an object to the same value. Or maybe top/bottom … left/right as a pair. For example, quite often I have to arrange some objects with help from a "sub"container, and to not to have extra paddings, it is nice to set them all to zero.

Now, with eg. containers there is lv_cont_set_fitX(), where X is “”, “2” or “4”.

How about having lv_obj_set_style_local_pad_all(), lv_obj_set_style_local_pad_tb() and lv_obj_set_style_local_pad_lr() (and non-local variants of those)? They would be so convenient to use

Then, a question on coding style (not that I’d have some pull request but merely as general interest). You accept only /* old style C comments */, why? Personally I think the C-adopted C++ -style one-liners encourage people to comment more!

Let’s compare.

// Label is common for all menu items except "value edit"
lv_obj_t *label = lv_label_create(btn, NULL);

…with…

/* Label is common for all menu items except "value edit" */
lv_obj_t *label = lv_label_create(btn, NULL);

I’d say the “space asterisk slash” at the end of a comment is so … well, heavy, that some people might unconsciously left the comment line out altogether - especially if one uses non-US layout keyboard. In my keyboard an asterisk and a slash are so far away from each other that I have to change hand’s position to get them consecutively. Maybe the real programmers use only US layout…

By the way, have you non-US-keyboard users ever wondered why e.g. microsoft uses “/?” to get help on their commands? Look where they are in US layout

[embeddedt]

@peejii73

How about having lv_obj_set_style_local_pad_all() , lv_obj_set_style_local_pad_tb() and lv_obj_set_style_local_pad_lr() (and non-local variants of those)? They would be so convenient to use

I think we can just add them as wrapper macros. It wouldn’t increase the code size or maintenance load. Can you send a pull request to master?

@peejii73

You accept only /* old style C comments */ , why? Personally I think the C-adopted C++ -style one-liners encourage people to comment more!

There was a time when we did our best to comply with C89, which didn’t support these comments.

I also personally prefer the appearance of the older comments; the newer comments just don’t look right to me, especially for multi-line comments.

/*
 * This is one way to write an older-style multi-line comment.
 * It uses a wall of asterisks on one side.
 */

// The newer-style multi-line comments use
// slashes on one side instead

All of that’s just personal opinion, though.

[peejii73]

Hi @embeddedt!

Thank you for your answer! I’ll try to implement those by myself (will check for macro vs. function first!) and if it is OK I’ll do the pull request. Whoa, LVGL contributor, me!

About C comments: I agree, multi line comments look better on standard C format. I still insist that those “quickies” in C++ style are nicer when scattered within the code.

LVGL application is usually like a prize day in a school: parents and their children jumbling everywhere. Sometimes it is difficult to keep log on who is who’s. Commenting helps!

Have a look:

if (DM_TYPE_SELECT == (item->type_n_flags & DM_TYPE_MASK)) {
    // SELECT: exit after selection: Simulate exit button!

    // Here's the underlying page
    obj = lv_obj_get_parent(obj);
    // Then, the main container
    obj = lv_obj_get_parent(obj);
    // Of which the top button (back, cancel ...) is a child
    obj = lv_obj_get_child_back(obj, NULL);

    lv_event_send(obj, LV_EVENT_CLICKED, NULL);
}

At least a quick glimpse does not mix up pointers and C-style comment asterisk

Well - as you said, at the end it is a matter of taste. I have bigger problems: I should convince people in the company I work for that TABS and indents of three spaces (done with tabs…) are both very bad idea

[embeddedt]

@peejii73

indents of three spaces (done with tabs…) are both very bad idea

Three spaces? I thought it was four!

@peejii73

At least a quick glimpse does not mix up pointers and C-style comment asterisk

That’s a good point. I always edit with syntax highlighting so that’s never been a problem for me, but I can see it being confusing without any highlighting.

[kisvegabor]

@peejii73
I like the idea. IMO inline functions would be the best choice as they are available i nthe micropython binding too (macros are not).

What about names like:

• lv_style_set_padding_all
• lv_style_set_padding_hor
• lv_style_set_padding_ver

Probably it’d be better for lv_cont_fit_2/4 too.

Regarding comment type, I see advantages and disadvantages for both I think’s important to use the comment types consequently to get a uniformed look. If we need to to choose one type I prefer /**/ because:

1. Not sensitive to line breaks, i.e. it’s easier to format
2. Trailing \ continues the comment in the next line. E.g.

char a = '\\';  // store special character: \
if(x == a)  // <-- also commented out

2. /**/ can be added inline (not sure it’s really important). E.g. if(a /*&& b*/)
3. Eclipse adds /** */ styled comments for Doxygen by default

[peejii73]

Hi,

The names you suggest are very good and self-explanatory. Who could easily guess that “_tb” suffix (as what I was thinking first) means TopBottom

I agree on those existing _2 / _4 functions too!

On commenting: we could argue this until the end of the world Anyhow, should I ever contribute something to LVGL, I’ll keep the rules in my mind.

@embeddedt: really, they use indentation on THREE spaces. It comes somewhere from distant past. I know nothing of it’s history, the only thing I’m sure about is that this style should be left there - in the distant past. Let’s keep fingers crossed.

[kisvegabor]

@peejii73

The names you suggest are very good and self-explanatory. Who could easily guess that “_tb” suffix (as what I was thinking first) means TopBottom

Great! Can you send a pull request?

@peejii73

On commenting: we could argue this until the end of the world

I agree
I don’t say /**/ really better than // but at least LVGL looks uniformed in this regard.

[peejii73]

Hi,

@kisvegabor

Great! Can you send a pull request?

Well, certainly - though I’ve never done this before on GitHub, I have to study it a little. Fortunately there is https://guides.github.com/activities/hello-world/

Please give me some time as I’m getting buried on my current project. Only 24 hours a day

Then, regarding to _2 / _4 functions, would it be OK to rename those thus breaking the API? Or maybe just leave them untouched saving people from search & replace… Parallel functions doing same things might be OK, but it sounds a little … well, not so professional.

More on implementation: I have noticed inline functions can cause problems in some environments. How about following the existing “set_fit / set_fit2 / set_fit4” scheme, ie. plain functions?

Cheers!

[embeddedt]

@peejii73

More on implementation: I have noticed inline functions can cause problems in some environments. How about following the existing “set_fit / set_fit2 / set_fit4” scheme, ie. plain functions?

We have used inline functions for a number of APIs already. Can you elaborate?

@peejii73

would it be OK to rename those thus breaking the API?

You can rename them and add macros with the old names to lv_api_map.h for backwards compatibility.

[BesitzeRuf]

Hi all,

@embeddedt

You can rename them and add macros with the old names to lv_api_map.h for backwards compatibility.

maybe just add new functions as inline functions (or vice-versa) in the same header file?

[embeddedt]

@BesitzeRuf

maybe just add new functions as inline functions (or vice-versa) in the same header file?

Exactly. A PR is open here: https://github.com/lvgl/lvgl/pull/1565