Follow up to "🚸 Update ProUI Plot graph (#26539)"

[classicrocker883]

Description

I wanted to make an update following #26539

• update ProUI for additional ICON_'s for new DWIN_SET
• update temp popup
• remove unused,
• rearrange/change ICON_ names
• rearrange enum PauseMessage
• add TJC support

Update

• update DWIN_ICO.py
• add extra ICON_'s to buildroot/share/dwin
• rename DACAI_ICON_Show => dacaiIconShow | ICON_Show => iconShow

I made a fix for this issue "[BUG] Unresponsive display with Hotend/Bed Temp Graph - PROUI_ITEM_PLOT https://github.com/MarlinFirmware/Marlin/issues/26630 "

• Update ID_MPC/PIDProcess with TERN_
• Fix Plot Temp Graph issue by making it return screen if there is a popup

Benefits

this updates proui/dwin.cpp menu ICON's with more variety.

• fixes some things that are unused and duplicates
• tweak it to be arranged better

Configurations

Related Issues

for the added EXTUI, I made some fixes to the errors which popped up.

• reverted allow_cold_extrude_override in src/module/temperature.cpp (which was removed??)
• fixed the no such file errors in moved lcd/dogm/u8g/
• various small tweaks to fix errors/warnings since EXTUI stuff was added.

[thinkyhead]

You'll need to rename Icon number 44 in the various icon packs from ICON_ResumeEEPROM to ICON_ResetEEPROM. I renamed this for clarity since it's being used as a stand-in for a more general "reset" icon.

[thinkyhead]

For best compatibility with Marlin's DWIN helper scripts, you'll want to organize custom icon packs into "icons-#" sub-folders with the same numbering and organization as the buildroot/share/dwin folder contents.

[thinkyhead]

What is the procedure to prepare icons 93, 200-206, and 250-254 ? and do these only pertain to TJC? We should add these to buildroot/share/dwin for completeness with our "unified" DWIN set.

[thinkyhead]

I've updated the contents of the buildroot/share/dwin folder, so it should now have everything needed to generate the numbered ICO files for sets 3, 4, and 7. If there's anything missing from that folder, now would be the best time to add the missing pieces.

[classicrocker883]

You'll need to rename Icon number 44 in the various icon packs from ICON_ResumeEEPROM to ICON_ResetEEPROM.

I suppose you mean within this PR here, Configurations #994?
Redoing each one is tedious just to rename one ICON name. I suppose I could do it, but it really doesn't matter with firmware implementation. I would only be able to do it for any labeled DWIN_SET and not for the other TJC "private" or DACAI.

~~let me know if you want me to do that. otherwise how it is now since you renamed to ICON_ResetEEPROM will be fine.~~

edit: I just did a test and whatever name you passthrough into creating the .ICO doesn't actually come back out when you split it. but for posterity I can go ahead rename # 44 of the .jpg itself.

[classicrocker883]

What is the procedure to prepare icons 93, 200-206, and 250-254 ? and do these only pertain to TJC? We should add these to buildroot/share/dwin for completeness with our "unified" DWIN set.

*it is actually 249-254

I do not know what others are supported in TJC, same goes for the "private" folder. I guess the same original icons work, but the added ones 93, 200-206, and 249-254 probably do not...

What do you mean by to prepare the icons?

so what I did was take the existing .jpg files, edit them in MS paint, literally pixel by pixel (since it is only 20x20 for the majority of them); remove the "noise" from the background, clean up anything to match the others, fix the loss of quality by the previous editor which happens when saving as .jpg. then I saved it as .png, then used something to convert to .jpg without losing any quality. after going through each one, I followed the instructions how to convert all of them to an .ICO and thats how you get your DWIN_SET.

[classicrocker883]

I've updated the contents of the buildroot/share/dwin folder, so it should now have everything needed to generate the numbered ICO files for sets 3, 4, and 7. If there's anything missing from that folder, now would be the best time to add the missing pieces.

I added the icon packs of the other DWIN_SET's as "icons-9". is this what you were looking for?

[thinkyhead]

I added the icon packs of the other DWIN_SET's as "icons-9". is this what you were looking for?

Not exactly. We're not supporting the original Creality set (icon set 9), only Marlin's (icon sets 3, 4, 7). So I'm just checking to make sure we have all the icons needed for that. It looks like ProUI is now using Icons numbered 93, 200-206, 249-254, so we need the standard icons added to Icon Set 7. I presume that Miguel has already added those icons and created new DWIN_SET / private folders that contain the updated icons for his distribution. We'll need those icons added to our own set 7 in order to support this updated ProUI code.

Note that after we get through this set of changes you should submit any changes we've made to mainline Marlin to the @mriscoc fork so that we are relatively in sync. In the long run it will be better for you to first submit any changes and fixes to that fork, and then we can coordinate with Miguel to bring those changes over en masse to this repo when he reaches a good milestone. The same goes for any other forks that are actively under development.

[classicrocker883]

question:
is there a way to make this work for all languages?
besides placing this in every language_xx.h file, since they are using namespace Language_en; anyway...
take the following in proui/dwin.h and place it in language/language_en.h

  #define _MSG_PREHEAT(N) \
    LSTR MSG_PREHEAT_##N                  = _UxGT("Preheat ") PREHEAT_## N ##_LABEL; \
    LSTR MSG_PREHEAT_## N ##_SETTINGS     = _UxGT("Preheat ") PREHEAT_## N ##_LABEL _UxGT(" Conf");
  #if PREHEAT_COUNT > 1
    REPEAT_S(2, INCREMENT(PREHEAT_COUNT), _MSG_PREHEAT)
  #endif

so then for instance, using the following as example
LSTR MSG_PREHEAT_M = _UxGT("Preheat $");
LSTR MSG_PREHEAT_M_SETTINGS = _UxGT("Preheat $ Conf");

could we just use it like this?

  #define _MSG_PREHEAT(N) \
    LSTR MSG_PREHEAT_##N                  = MSG_PREHEAT_M PREHEAT_## N ##_LABEL; \
    LSTR MSG_PREHEAT_## N ##_SETTINGS     = MSG_PREHEAT_M_SETTINGS PREHEAT_## N ##_LABEL;
  ...

would this just replace the $? or how would that work?

[thinkyhead]

would this just replace the $? or how would that work?

I didn't pay closest attention when Miguel implemented the string substitution stuff in the last update, and after a cursory look at the menu code in dwin.cpp it looks like basic language support with string substitution is still incomplete in ProUI. Hopefully that will be added pretty soon. In the meantime we'll just retain the current workaround.

[classicrocker883]

you know the change in "remove non-translated atoms", commit 620aa67
how about making that a language string?:

  LSTR MSG_PID_SET_KP   = _UxGT("Set" STR_KP);
  LSTR MSG_PID_SET_KI   = _UxGT("Set" STR_KI);
  LSTR MSG_PID_SET_KD   = _UxGT("Set" STR_KD);

[classicrocker883]

it looks like basic language support with string substitution is still incomplete in ProUI. Hopefully that will be added pretty soon. In the meantime we'll just retain the current workaround.

is that what you mean? to basically replace all the strings as MSG_<whatever>?

I know in his ProUI fork, almost all the menu strings seem to be incorporated within language_en.h namespace
for quick reference, at near the end of it:

  // DWIN_LCD_PROUI specific message strings
  LSTR MSG_BED_TEMPERATURE      = _UxGT("Bed Temperature");
  LSTR MSG_NOZZLE_TEMPERATURE   = _UxGT("Nozzle temperature");
  LSTR MSG_TOO_HIGH             = _UxGT("is too high");
  LSTR MSG_TOO_LOW              = _UxGT("is too low");
  LSTR MSG_HOTEND_PID_SETTINGS  = _UxGT(STR_HOTEND_PID " Settings");
  LSTR MSG_BED_PID_SETTINGS     = _UxGT(STR_BED_PID " Settings");

but I was thinking... instead of placing that at the end of the main LanguageNarrow_en namespace
we can use the next namespace since it uses HAS_DWIN_E3V2.

namespace LanguageWide_en {
  using namespace LanguageNarrow_en;
  #if LCD_WIDTH >= 20 || HAS_DWIN_E3V2

[thinkyhead]

I know in his ProUI fork, almost all the menu strings seem to be incorporated within language_en.h namespace. For quick reference, at near the end of it…

It's fine for the "narrow" language strings to be there if they are 20 characters or less. But the wider strings should definitely be moved to the LanguageWide_en namespace.

is that what you mean? to basically replace all the strings as MSG_<whatever>?

All strings that appear on an LCD should use the defined MSG_ strings and GET_TEXT / GET_TEXT_F macros to access them. These transparently manage language translation.

But in terms of "substitution" any string with a special character ($*@{) filtered through the appropriate lcd string methods will get substitutions regardless of the string's source.

[thinkyhead]

Our Configurations repository is the official home for the Marlin 2.1.x-compatible DWIN DWIN_SET folder, DACAI private folder, and (now) the tjc.tft set. So all those sets need to get the new icons added. I already went ahead and added the new icons to DWIN_SET/7.ICO. So they just need to be added to the DACAI private set and tjc.tft. At that point this PR will be compatible with the configs and both can be merged.

I can go ahead and put the new JPEG files into the private folder, but I'm not versed on how to make the 7.zico file. Maybe the format is obvious after comparing its contents to the size and length of the JPGs. We'll see….

[mriscoc]

I presume that Miguel has already added those icons and created new DWIN_SET / private folders that contain the updated icons for his distribution.

No, I use the default Creality Icon set and not added by default any custom icon to try to avoid screen firmware updates, but I added a custom function to allow to use and extended icon library "10.ICO" (which can fallback to "9.ICO") if custom icons are needed.

Currently, Marlin ProUI has diverged a lot from my original implementation and it is a little difficult to get them in sync again.

About the ($*@{) string substitution, I am not convinced that implementing the substitution routines in ProUI will give a more compact compiled code, I'm struggling for every byte due to the program memory limitations in STM32F4XXX RCT6 SoC's.

[thinkyhead]

I use the default Creality Icon set and not added by default any custom icon to try to avoid screen firmware updates

Hmm, well on the one hand, I don't want users to lose the ability to use ProUI without a display update. On the other hand, now we have this PR here with improved cleaner icons, so it makes sense that your Professional Firmware should be able to take advantage of these improvements as well. And really, if you were to insist that your users must update the screen to use the next version of ProUI, I believe very few would complain. It's a pretty easy process and users will consider the improvements over CrealityUI worth the extra step.

Currently, Marlin ProUI has diverged a lot from my original implementation and it is a little difficult to get them in sync again.

I'm here to help if you run into snags. You can get in touch with me pretty quickly on Discord whenever a question arises.

We're always aiming for better standardization. Consistent language translations and menu titles is one area that we would really like to get nailed down. I also plan to add an ExtUI layer to ProUI and other displays so they no longer require custom callbacks to be scattered throughout the code but will just intercept a single ExtUI event callback at each location. Where ExtUI doesn't currently have an event callback that ProUI or another display needs, we will simply extend the ExtUI API.

If you plan to keep developing ProUI as we enter the Next Phase then we'll need to work more closely to develop sensible APIs and utilities that fit your needs and the needs of similar UIs. It will be important to keep your fork as close to the main fork to keep in sync without a lot of duplicated effort.

A problem with divergent forks of Marlin is that other contributors end up cherry-picking bits and pieces and bringing them here for integration. Since there's no compelling reason for us to refuse a good improvement, we obediently fix it up and integrate it, but it can never match up to the completeness of your own work. So it's always better if your changes are in sync with ours, and vice-versa. That is what we ought to strive for on an ideal planet.

This PR has consumed a few days of productive time. I would much rather be working directly with you instead of intermediaries on these APIs and integrations. (The author of this PR is cool, but we get some real "characters" sometimes.)

I am not convinced that implementing the substitution routines in ProUI will give a more compact compiled code

We can still do a lot of things to optimize the code and keep it from exploding, so don't hesitate to proceed on that concern. The "LCD String API" is another important area of standardization. You'll be needing it if you want ProUI to use translated strings that have different orderings, adapt to changes in the number of extruders and preheat presets, and so on. It will not increase code size because we can do things like replace 5 menu items with a loop that only emits one menu item 5 times, but with different E indexes (for example). And only a small number of menu items will actually be affected. The string interpolation function is also quite small.

I'm struggling for every byte due to the program memory limitations in STM32F4XXX RCT6 SoC's

Welcome to my world. I still lose sleep worrying about old Melzi board support. My background is in tiny 6502 computers where every byte counts. So you couldn't ask for a better partner in space-saving than "yours truly."

Anyway, stay in touch! We'll get these things sorted out in time, I'm sure. Note that I am planning a 2.1.3 (or 2.2.0??) release pretty soon, now that Fixed-Time Motion is integrated and we have a long list of bug-fixes. After that release I will be working on LCD standardization in earnest. I'll be sure to let you know as soon as I get started on that process.

[classicrocker883]

So they just need to be added to the DACAI private set and tjc.tft. I can go ahead and put the new JPEG files into the private folder, but I'm not versed on how to make the 7.zico file. Maybe the format is obvious after comparing its contents to the size and length of the JPGs. We'll see….

that would be great! I couldn't find any information about it myself. I was able to extract non-working .jpg using Split-ico.py from the .zico file, that is it was able to grab all the files, but not give anything to work with. maybe someone at Creality or where ever .zico, TJC, DACAI... originates from knows and has the proper tools.

On the other hand, now we have this PR here with improved cleaner icons, so it makes sense that your Professional Firmware should be able to take advantage of these improvements as well.

some of the ICONs (anything > #91) already exist in the DWIN_SETs which many users may already have installed - especially if they are coming from JyersUI. so why not use them. plus while I was cleaning up the original ones, I added one of my own, 093-ICON_Printer_0.jpg (generic Ender-3 style). Its good to use for when Homing or an error. I left it open-ended with Printer_1 for maybe a different type or whatever. unfortunately, I wasnt able to do anything about #78-81 which is 73x66 px. I mean I was able to clean it up, but after installing it appeared to go through a shredder. So I just left them original despite the kinda of pixel haze (typical when saving into .jpg).

furthermore, if anyone wishes to edit .jpg, unless you have a professional app which saves .jpg without losing quality, you have to save as .png. then I used a website which is able to convert .png to .jpg and it doesn't mess with the image. thats how I got it cleaned up, and no doubt why they became messy to begin with.

I am not convinced that implementing the substitution routines in ProUI will give a more compact compiled code

I think when I changed a lot of the " string " to MSG_ in my own, I noticed it reduced the byte size in the end.

[classicrocker883]

this is already ready for review

[thinkyhead]

Before this can be merged I want to make sure we have complete sets for DWIN, DACAI, and TJC and that they are all fully compatible with this update. Last I checked we didn't even know how to update the TJC set.

[classicrocker883]

Before this can be merged I want to make sure we have complete sets for DWIN, DACAI, and TJC and that they are all fully compatible with this update. Last I checked we didn't even know how to update the TJC set.

I want to say that this PR should be ready to merge on its own. regarding DACAI and TJC - having their Macros defined should enable compatibility.
I think you are concerned about the updated DWIN_SET? Although I have yet to figure out changing/updating a different type of set, but I have already compensated for that in the other PR I have.

ex:

dwinShowPopup(TERN(TJC_DISPLAY, ICON_BLTouch, ICON_Printer_0)

since they dont have the new ICON_Printer_0, it uses one it does have.
I should also update this so it includes DACAI as well.

[thinkyhead]

I spent a few days to put more methods into ExtUI for some events it wasn't handling yet and made an ExtUI layer for ProUI to replace several of the ProUI-specific calls throughout the code. There are still some ProUI-specific customizations, but most have been shifted over to ExtUI. I don't expect the initial attempt to pass CI testing, so pardon the mess as I try to get it patched up without piling on several new commits….

[mriscoc]

I spent a few days to put more methods into ExtUI for some events it wasn't handling yet and made an ExtUI layer for ProUI to replace several of the ProUI-specific calls throughout the code. There are still some ProUI-specific customizations, but most have been shifted over to ExtUI. I don't expect the initial attempt to pass CI testing, so pardon the mess as I try to get it patched up without piling on several new commits….

For referencie some work was already made some time ago for port ProUI to ExtUI here: https://github.com/MarlinFirmware/Marlin/pull/21328 of course that work is now obsolete. I think that moving ProUI to ExtUI should have a separate PR.

[convicte]

This seems to have had some unintended consequences breaking LCD support for among others Anycubic Viper

Marlin\src\inc\Warnings.cpp:115:6: warning: #warning "Note: Auto-assigned LCD_SERIAL_PORT. (Define NO_AUTO_ASSIGN_WARNING to suppress this warning.)" [-Wcpp]
  115 |     #warning "Note: Auto-assigned LCD_SERIAL_PORT. (Define NO_AUTO_ASSIGN_WARNING to suppress this warning.)"
      |      ^~~~~~~
Marlin\src\inc\Warnings.cpp:223:6: warning: #warning "Note: Auto-assigned Z2 STEP/DIR/ENABLE_PINs to unused En_STEP/DIR/ENABLE_PINs. (Define NO_AUTO_ASSIGN_WARNING to suppress this warning.)" [-Wcpp]
  223 |     #warning "Note: Auto-assigned Z2 STEP/DIR/ENABLE_PINs to unused En_STEP/DIR/ENABLE_PINs. (Define NO_AUTO_ASSIGN_WARNING to suppress this warning.)"
      |      ^~~~~~~
Marlin\src\inc\Warnings.cpp:760:4: warning: #warning "GD32 based controllers may not be fully compatible with STM32 platforms. Please report any issues." [-Wcpp]
  760 |   #warning "GD32 based controllers may not be fully compatible with STM32 platforms. Please report any issues."
      |    ^~~~~~~
c:/users/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio/build/trigorilla_v006/src/src/gcode/config/M302.cpp.o: in function `GcodeSuite::M302()':
C:\Users\Documents\GitHub\Marlin/Marlin\src\gcode\config/M302.cpp:54: undefined reference to `ExtUI::onSetMinExtrusionTemp(short)'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\trigorilla_v006\firmware.elf] Error 1