[FEATURE REQUEST] Redesign the Queue an make a class for each screen type

[lubeda]

The class EHMTX_queue; does not fit the features anymore.

There should be more dynamic std::list instead, and there should be a class for each screen type to move the complexity from void EHMTX_queue::draw() to the separate screen classes. The base class should only contain the attributes common to all screens. I started to "sketch" it in m8trx32.h, but I have no time to develop this right now.

The result would be a much cleaner code with more dynamic, the number of different screens would be limited only by RAM. The screen identifier could be cleanly separated from the icon into an attribute, instead of the workaround with the "|". So it would also be possible to have multiple bitmap_screen if there is enough RAM.

[lubeda]

So every thing that is now done in the crazy switch statements could- be sorted into the clases

so no more:

switch (this->queue[i]->mode)
              {
              case MODE_EMPTY:
                break;
              case MODE_BLANK:
                infotext = "blank";
                break;
              case MODE_COLOR:
                infotext = "color";
                break;
              case MODE_CLOCK:
                infotext = "clock";
                break;
              case MODE_DATE:

[andrewjswan]

Great news, but I'm not much help here, I don't know C++. :)

[andrewjswan]

Since we abstract from the monolithic system, and make a modular one in which each page is a separate module with its own requisites. It seems to me that it would be good to transfer settings from the general config to the individual one for a page.

• time_format: "%H:%M"
• date_format: "%d.%m."
• rtl: false [FEATURE REQUEST] RTL: set RTL per screen or new modes per screen #39
• weekdays: "SUMOTUWETHFRSA"
• replace_time_date_to and replace_time_date_from
  So we can flexibly manage the display, and we can display time and date in different formats in dynamics.

PS: In principle we can leave this in the general config as a default value for screens that don't have these individual settings.

[andrewjswan]

This will allow to display the date in 2 or 3 languages, for me it would be relevant Ukrainian, English, Korean, for our relatives, Spanish, English, Ukrainian. Now it is not possible. But in the new structure I don't see any obstacles.

[lubeda]

You have a very seldom use case but you're right. Problematic are the service calls from home assistant, there are no default parameters. So instead a
of the normal parameter like the font color etc. you have to specify rtl, date format and the rest. This is "uncool" and makes using the ulanzi more user unfriendly.

[andrewjswan]

I was going to open an Issue in ESPHome about this, if it is not possible to set opional parameters in a service call. But if it is really impossible, although declared services in ESPHome Yaml can do it, and ywe can try to do it through them, then we can make a limited set of calls for each service with a different set of parameters.

[andrewjswan]

Like

api:
  services:
    - service: show_screen_message
      variables:
        message: string
        mode: int
...
      then:
...

[andrewjswan]

esphome/issues#4996

[andrewjswan]

If you can make a working version with at least one fully working screen, I'll try to add the others.
I think it will be easier that way. And maybe faster.

[andrewjswan]

And we can give only necessary parameters to the services, and everything else (rarely used) can be done through the ESPHome API, like here #96 (comment)

[lubeda]

When redesigning the queue the "icon|screen_id" syntax should be questioned. Also the now (thanks to @andrewjswan) more than 20 different screens are very confusing to beginners. Perhaps there is a way to make the service calls easier. The esphome api especially the service calls are the limiting factor.

i have got no time to think about it in detail or even start coding, but using ehmtx should never be as hard as rocket-science.

[andrewjswan]

I found such a code in ESPHome, it registers the service registered in the API section, and it does not require complete completion of all parameters, maybe this will help us somehow?

  api_apiserver = new api::APIServer();
  api_apiserver->set_component_source("api");
  App.register_component(api_apiserver);
  api_apiserver->set_port(6053);
  api_apiserver->set_password("");
  api_apiserver->set_reboot_timeout(0);
  api_userservicetrigger = new api::UserServiceTrigger<std::string, int32_t>("show_display_message", {"message", "type"});
  api_apiserver->register_user_service(api_userservicetrigger);
  automation_2 = new Automation<std::string, int32_t>(api_userservicetrigger);