[RFC, 2.0.x] Proposed Menu Reorganization

[marcio-ao]

Hello,

As some of you may know, our LulzBot printers use a modified branch of the Marlin FW. One of the things that I do is tweak is the structure of the menu system so it is more understandable to our users. Since doing these modifications to each release of Marlin takes a certain amount of effort, I thought I would ask whether there would be an interest in adopting this re-organized menu structure in Marlin 2.0 upstream

Here is a diagram of the current layout and the layout which I am proposing (which is pretty much the layout we use in our customized FW right now):

The stuff in italics is hidden in our FW, but I am assuming those would be left visible in Marlin, if these menus were adopted, so it would match the current menu interface. The reasons the choices were made:

• Moves most often used choices to the top 5 slots so it is visible on the RepRap Discount display, or accessible with less scrolling on smaller displays.
• The distinction between "Movement" and "Temperature" seems more obvious than those between "Prepare" and "Control".
• Moves the "Change Filament" to the top, so it can be used either when printing or when idle.
• Moves the lesser used configuration into an "Advanced Settings" menu.
• The "Tune" menu remains the same.

If there is an interest in this and everybody is on board with it, I could create a PR for the 2.0.x branch.

-- Marcio

[landodragon141]

I think this is great. It would be nice if the menus were recoded to use the trick from the Lightweight UI as well. In addition it should be easily extensible so that it is a simple matter to add menus for different features. For instance adding a menu for TMC_Drivers. This may just be my feeling but I would like the ability to run pretty much any gcode command via the display. Maybe we could add in a custom gcode command input. Sure it's not efficient compared to using the terminal but I've had times when I wish I didn't need to haul my computer along to do certain things.

[teemuatlut]

I'm working on a TMC menu for 2.0.x but the current LCD macros don't necessarily suit my needs.

[marcio-ao]

It would be nice if the menus were recoded to use the trick from the Lightweight UI as well.

I've considered that possibility, but that would be a much larger project. The changes I proposed above can be done with relatively few modifications to the ultralcd code.

Making a full lightweight ST7920 menu system would be considerably more work. The font in the ST7920 chip is also much larger than the one currently used in the menu and can only show 16x4 characters. That is a big step down from what the current menu supports, so I suspect most people will not like the change.

[landodragon141]

I don't disagree that my suggestions would be best suited to a dedicated project. I'm more or less taking advantage of this post to get some more discussion in the community.

Speaking of the Lightweight ST7920 there is a compile error when using UBL I need to put a pull request in for a fix for that one.

[AJMartel]

I would be interested in these modifications, though I would not want any of the options hidden.

[kAdonis]

Yes, this menu structure is more intuitive

[marcio-ao]

I would be interested in these modifications, though I would not want any of the options hidden.

I guess I should clarify that I do not intend to have those hidden in upstream Marlin. They just happen to be hidden in LulzBot firmware.

[TheSFReader]

I also would welcome that reorganization.

[Roxy-3D]

I think this organization is easier to find things. I would put Z-Offset into Bed Leveling however.

The LCD code needs to be re-written. It would be good if some 'reasonable' menu tree was defined but the user could easily move things around to what makes sense for them (and the machine).

[marcio-ao]

I've also received a request from our users to add a "yes/no" confirmation before "Stop Print" or "Change Filament"

[marcio-ao]

@Roxy-3D: I think the Z-Offset has been traditionally in Configuration because it is something that is stored in the EEPROM. It also appears as if Bed Leveling is not a submenu item, it simply causes G29 to run.

[Roxy-3D]

Yeah... I understand why you have it proposed to be in Configuration.

I'm just kind of saying "Yeah but..." because the only reason to have a Z-Probe is because it is being used to do bed leveling. It maybe it makes sense to have it in both places. But the better (long term) answer is to make it so easy for the user to customize the menu structure on their machine that they can just move it where ever they want it to be.

[thinkyhead]

@marcio-ao: …the structure of the menu system…

I like it overall, though I'd recommend maybe rearranging certain items (e.g., have the Movement submenu match the order of the Prepare submenu).

---

@landodragon141: Lightweight ST7920 … compile error … using UBL

I may be able to "hotfix" that. If it isn't fixed tonight, go ahead and add a PR.

---

@Roxy-3D: I would put Z-Offset into Bed Leveling however.

Makes sense.

The LCD code needs to be re-written.

A re-organization would be a good starting-point. I made a branch where all the menu items are moved into a separate file and all the LCD code is better-organized, but it's too big a change to do while other PRs that want to alter ultralcd.cpp are still extant. You can see it at https://github.com/thinkyhead/Marlin/commits/bf1_menu_refactor

The other good option would be to allow multiple languages to be enabled at the same time. But this is a slightly major change. And we should definitely merge #10213 before going there.

---

@marcio-ao: It also appears as if Bed Leveling is not a submenu item

As I recall, it is a full sub-menu when LCD_BED_LEVELING is enabled, otherwise it's just a simple G29.

add a "yes/no" confirmation

I've been wanting to add a general single-screen that shows "No" on one side and "Yes" on the other, with custom text at the top. You'd scroll left to choose "No" and right to highlight "Yes." The "Yes/No" would be translated into the current language.

And, some menu edit items might benefit from having a graphical "progress bar" while editing values.

---

@teemuatlut: the current LCD macros don't necessarily suit my needs

They're pretty flexible if callbacks are used. What is it you need to do that isn't yet implemented?

[teemuatlut]

I seem to recall that when trying to set up current control, the steps for the value were 100 units each and I'd like to have 10mA or 20mA steps. There will likely be other cases too where I'd like to have more control over the granularity once I get back to writing everything.

[thinkyhead]

@teemuatlut — The increment depends on the type of value edit you use. The lines where these callbacks are created are…

  DEFINE_MENU_EDIT_TYPE(uint32_t, long5, ftostr5rj, 0.01);
  DEFINE_MENU_EDIT_TYPE(int16_t, int3, itostr3, 1);
  DEFINE_MENU_EDIT_TYPE(uint8_t, int8, i8tostr3, 1);
  DEFINE_MENU_EDIT_TYPE(float, float3, ftostr3, 1.0);
  DEFINE_MENU_EDIT_TYPE(float, float32, ftostr32, 100.0);
  DEFINE_MENU_EDIT_TYPE(float, float43, ftostr43sign, 1000.0);
  DEFINE_MENU_EDIT_TYPE(float, float5, ftostr5rj, 0.01);
  DEFINE_MENU_EDIT_TYPE(float, float51, ftostr51sign, 10.0);
  DEFINE_MENU_EDIT_TYPE(float, float52, ftostr52sign, 100.0);
  DEFINE_MENU_EDIT_TYPE(float, float62, ftostr62rj, 100.0);

So, for example, if your edit item is a MENU_ITEM_EDIT(float32, ...) then the scale is 1/100 of the full range. Each type has its own scale-factor, and you can add your own if none of the others is suitable.

[marcio-ao]

A re-organization would be a good starting-point. I made a branch where all the menu items are moved into a separate file and all the LCD code is better-organized, but it's too big a change to do while other PRs that want to alter ultralcd.cpp are still extant.

@thinkyhead : Do you want me to create a PR with the proposed menu changes to 2.0.x, or do you wish to add your changes first? I want to make sure I don't step on your toes.

[marcio-ao]

I put in the PR for this change. I left the "Tune" menu as is in order to avoid making too many changes at once, so the Z-offset is still where it was before. Overall, most of the work was accomplished by renaming menus, so not that much moved around.

[marcio-ao]

Closing this since this has been merged

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.