Observer Enhancement

[vwheeler63]

Introduce the problem

While I was re-writing and reviewing the documentation for Observer, I noticed a couple of logic gaps, which I am predicting will be needed in the future:

• Currently FLAG and STATE combinations can be set or cleared by an Observer based on EQUALITY or INEQUALITY with a reference value. However, I am predicting this will be also needed for the following integer comparison operations with <, <=, >=, > suggesting additional lv_obj_bind_...() functions. Note that only the first 2 of those could be implemented plus a "not" flag to control the execution path during testing, so it would only take 3 bits to manage (2 more bits in the flag_and_cond_t struct) to manage, no matter now it was organized. (No additional RAM cost.)

• Each Subject carries a prev_value field, but the only place it is actually used is in these query functions:

  • lv_subject_get_previous_int()
  • lv_subject_get_previous_string()
  • lv_subject_get_previous_pointer()
  • lv_subject_get_previous_color()

While the latter is fine as a "minimal" implementation, there is an important UI design pattern that minimizes CPU overhead (extremely important in my opinion in some RTOS environments) that:

• Only does an update on the Widgets ONCE immediately before each screen refresh, and

• ONLY does so (for each Widget) when it will result in a visible change on the display, and this pattern especially avoids doing an update when the value displayed has not changed, since it incurs an lv_obj_invalidate(), which forces re-drawing, which is then a large-and-unnecessary source of CPU overhead that would result in no visible change on the display.

This pattern begs for Observer-notification filtering such that (when desired) that only sends out a notification when the NEW (incoming) value (in the various lv_subject_set_...() and lv_subject_copy_string() functions) is actually different from the previous value. All the logic (and data) to implement this capability this is already contained in the implementation except for the flag indicating when this filtering is desired.

Proposal

That the above features be added. I would definitely use it in our Dashboards if it were available to set a "widget_needs_updating" flag for each Widget so affected. It would simplify a lot of logic I have currently implemented to accomplish this (embedded in each screen's Update() function -- I have a screen "class" that always has an Update() function that gets called once, immediately before the display refresh).

I was thinking these features could perhaps be planned for the next major release (low priority).

Thoughts?