Style - What is the 'sb' property referring to?

General discussion
1

I am creating some custom themes and understand what most styles are but I cannot understand what the ‘sb’ is relating to!

style.list.sb
style.ta.sb
etc

Other things i can work out: bg = background, scrl = scroll bar, btn = button. But not sure what sb means and changing this, specifically in the text area, does not seem to do anything!

In the interest of ‘Clean Code’ it might be worth giving things full, non-abbreviated, names in a future release. Although I can appreciate this causing backward compatibility issues.

2

I’m still confused. ta (text area) has the following styles:
lv_style_t * area;
lv_style_t * oneline;
lv_style_t * cursor;
lv_style_t * sb;

Area appears to be the main property to allow you to change the text box colour, border etc.
I guess cursor, if not NULL allows you to set the cursor colour.
What is oneline and sb??

3

I think these are the only styles you are supposed to manipulate: https://docs.littlevgl.com/en/html/object-types/ta.html#style-usage

For page-based objects (like text areas), scrl is the scrollable area (which is implemented as a child object) and sb is the scroll bar.

4

Scrollbar, that makes sense, and explains why changing this property isn’t doing anything for me as i’m using a single line.

So does that mean that Oneline and Cursor(?) should really be removed from the Theme struct if its not used? Although I’m guessing that Cursor is used depending on the cursor mode selected!

5

Read this carefully. https://docs.littlevgl.com/en/html/object-types/ta.html#style-usage

LV_TA_STYLE_CURSOR - cursor style. If NULL then the library sets a style automatically

I haven’t had a chance to check the code but oneline is probably used automatically when oneline mode is enabled.

6

IMHO styles and themes fee like something that needs some work. They seem to have grown organically, and could use some tooling.

For example, let’s say you want to change all your objects to use pretty color. You have two options, both of which are time consuming:

  1. Create a new theme
  2. Change every style by hand

It would be nice if we could do this universally

This is an example

7

@rohmer
Please open a new topic to discuss it in the Feature request category.

1 Like
8

sb is really not so self-explaining. Do you have any suggestions on how to change it? SCROLLBAR is too long IMO. What about SCRLBAR?

9

Why it is too long? too long for what? using SCRLBAR you have only removed 2 characters and made it slightly less readable.

Again, going back to clean coding it says you shouldn’t abbreviate, and I agree with this.

10

That’s correct. If SCRLBAR is ok then SCROLLBAR should be fine too.

Probably we should reconsider at least the “2 letters” abbreviations in the API such as ta and cb.

11

Sorry what I meant was I would rather just use SCROLLBAR instead of the slightly shorter version.

scr should be screen (i believe thats what it means!)
bg becomes background
cont becomes container
rel becomes release
etc, etc, just say what it is
I would even make tgl_rel toggle_release etc

I have also noticed, going though lv_theme_t, that there are some larger, better named items such as day_names, highlighted_days etc. These are perfect and very clear.

And while we are on the subject (or maybe this should be for a feature topic) the label structure appears, as far as I can tell, to be optional. So i would be tempted to remove this altogether.

Please don’t take this as moaning, I’m not, just constructive feedback :smile:

12

One “pro” for shorter naming conventions is that it saves typing during modification. To me there’s a tradeoff between having it short and easy to type, or making it long and expecting the user to have autocompletion or type it by hand.

In my opinion, having a clear mapping in the documentation between abbreviations and their meaning is acceptable. Once you know that rel means release you probably aren’t going to forget it too easily.

Feedback is appreciated!

13

I was thinking a lot about REL, scr, btn and similar abbreviations. IMO long names like
lv_button_set_state(my_button, LV_BUTTON_STATE_RELEASED)
are hard to read because the gist loses in the long expressions.

Just to compare:
lv_btn_set_state(my_btn1, LV_BTN_STATE_REL)

So my principle was to find a balance between easy recognition and length. However, I really failed with sb because it’s hard to recognize. :slight_smile:

14

I know what you are saying, and we might just have to agree to disagree on this :slight_smile: … However:

Is this really that hard to read or remember?

Also the trouble with abbreviations is people might think they should be abbreviated differently, I could argue you have already done that. You have made Release Rel, yet you have made Button Btn, why not But? or make Release Rls?

Whereas using the full name there is no ambiguity, button is button :slight_smile:

This would then make it easy to come up with a better name for sb, as it would be ‘scrollbar’ :stuck_out_tongue:

15

Again, I would argue that if you someone doesn’t understand an abbreviation they could just look it up in the documentation (which they should have already read anyways :wink: ).

16

Agreed, but looking it up once to understand it is one thing. Looking it up several times to remind yourself what abbreviation was used is another :wink:

17

Also the trouble with abbreviations is people might think they should be abbreviated differently

True, it’s arbitrary. However, I’ve never heard other abbreviations for button than btn.

Just to show an example which would look really ugly without abbreviation:

lv_btnm_set_style(my_btnm1, LV_BTNM_STYLE_BTN_TGL_REL, my_style1)

or

lv_button_matrix_set_style(my_buttonmatrix1, LV_BUTTONMATRIX_STYLE_BUTTON_TOGGLE_RELEASED, my_style1)

Refactoring the whole lib is definitely out of scope now, but I agree to update the most ambiguous abbreviations.

Usually, I use the full names in the comments, so it should be one click to see what a defines/enum really means.

My rule was to keep names <= 8 char long (also arbitrary). With this in mind:
ta -> textarea
cb -> checkbox
sb -> scrlbar(7) or scrollbar (9) (scrl is used in lot of places)

1 Like
18

This sounds like a reasonable compromise :crazy_face:
Thanks for its consideration.

19

Does this apply to all APIs (lv_ta_create -> lv_textarea_create) or just the styles?

If we change all the API names as well I’m not sure what the reaction will be.

20

Could both be supported for backward compatibility? So lv_ta_create becomes:

lv_obj_t * lv_ta_create(lv_obj_t * par, const lv_obj_t * copy)
{
lv_obj_t * lv_textarea_create(par, copy);
}