Screens could link to child menus

[DanielW0830]

Was wondering if this sounded like a good request.
Screens could have attached menus.

Screen.attach_menu(ConfigMenu);
Then, no callbacks would be needed to traverse menus.
The ConfigMenu _parent variable is set to the parent of the screen.

When you select a screen, it would take you to the attached menu.

then if you want to go back
CurrentMenu.go_to_parent(); //if no parent, just returns same menu

Dan

[VasilKalchev]

If I understand right you are looking for the LiquidSystem class. Take a look at this example: H_system_menu.

Let me know if I misunderstood you.

[DanielW0830]

Yes, that's a very good example.
I'm suggesting one step further.
In the example you say: "This method can be wrapped inside a callback function and called on through the menu."

This is good. But I have an idea. :)
Let's say Screens had a method to add a menu (or maybe a constructor)
Now if someone selects the screen, instead of calling a callback, the screen would just go to the menu it has attached. Then when a "back" method is called on a menu, it would go back to the parent menu that it came from.

In this way, navigating multiple menus would be so easy.
(Btw, I implemented the menu system for some military helicopters. :) )

No callbacks would need to be added, and the menus would be smart enough to navigate with just two methods. :)

What do you think?

Dan

[DanielW0830]

Another thing I've done in the past is have a line item have a on_changed method.
void on_changed(LiquidLine *pLiquidLine)
Then, a line could have an inc() & dec() function.
as it changes, the on_changed gets called an the user can decide what to do when a variable hits a limit.

[DanielW0830]

In your example, you call this a bunch of times. All these calls and callbacks could be eliminated.
outputs_line.attach_function(1, goto_outputs_menu);

instead, switch_focus() would jump right to the attached menu.
and a call to .menu_back() on a screen would get you to the previous menu.
(or the same menu if there is no parent menu attached)

Here's an overview:

menu1
screen1
screen2
screen3
screen4 -> (has attached menu, selecting calls change_focus() )
menu2
screen1
screen2
screen3 (calling .menu_back() goes to menu1,screen4)
screen5
screen6

menu3
screen1
screen2
screen3 -> menu4
screen1
screen2
screen3
screen4 (calling .menu_back() goes to menu3,screen3)

screen4 ->   menu5
		         screen1
		         screen2
		         screen3
		         screen4  (calling   .menu_back()   goes to 

menu3,screen4)

[VasilKalchev]

I agree, this will make it more intuitive to navigate menus. The problem is that this library is using a lot of RAM because it uses static memory for the arrays that hold the functions callbacks, the variables pointers and their types, the LiquidLine pointers inside the LiquidScreen and so on. To attach a LiquidMenu to a LiquidLine I'll have to add two more LiquidMenu pointers inside LiquidLine which will increase the size of every LiquidLine object and the statically allocated memory for the callback functions will be less utilized.

I can't add this functionality for now, but I'll definitely add it in the future if I update the library to use dynamic memory.