Thanks a lot!

It is modeled after blender's UI

Sorry, I don't have the source code anymore

What format was the graphics on the SD card?

@@kacjan4950 raw byte stream. The image was rescaled to the LCD's size and then stored frame by frame on sd card

Hello Leonardo How the menu (or the GUI for that mater) works is not that complicated. I set up a tree of widgets in the memory and I render them each frame. While the widgets are redrawn each frame, the entire GUI is maintained in memory between the frames. So while rendering the GUI is like in the immediate mode GUIs, setting up actually the GUI itself is like in traditional GUI systems, like windows for example. In the case of the menu, there are two widgets, one called MenuBar handling the menu bar itself and another called Menu, which handles the submenus. When the menu itself is created, I create a MenuBar and then create each Menu and add it as a child of the MenuBar. (The menu items themselves in the menu are actually another object called Action, which contains a text, an icon, event handlers and state and is also used in other parts of the GUI, like buttons, and rendered accordingly by each widget using it. This way I can use for example the same Action for a button and a menu item and when I disable the action, it will disable both the menu item and the button). Once everything is set up, on each frame the entire menu and it's menu items are rendered according to their state, first the MenuBar, then the Menus and SubMenus. Once rendering is complete the GUI will start handling the various events (hover, enter widget area, leave widget area, click, and so on) and call their handlers which in turn will update the state of the widget itself. For example in case of the Menubar, if one of the menus are hovered by the cursor, will mark the menu hovered. If menu is displayed, and the mouse cursor is over a menu item, it will mark the menu item hovered. On the next frame, the render code runs again, but this time possibly with the new states set up by the event handlers or the application code, so if previously a menu bar become hovered in the last frame, when rendering the new frame, the render code will detect it is hovered so it will render it accordingly - like for example selected. This cycle repeats for all widgets in the GUI until application exits.

@@jancsifarkas5164 Thank you so much for answering me. The concept of the menu hierarchy is what I considered too. The menu items I create when I create the window and I will destroy them when I close the window. The problem is in the details, for now all the labels are rendered one above the other. I will have to study a strategy. The concept of "event management" is still unknown to me, I have to understand how it works. Question: but do you redenerate the bar and then the menu object, or, in rendering the bar, do you also have the menu also rendered? There are many things that I still don't know, ... we'll see in the next few days. Thanks for now.

@@leonardochiruzzi7642 I don't regenerate anyhing. The hierarchy is built and I only change it when it is the case as result of an action. In case of an immediate GUI you have something like: render_frame() { create menubar create menu 1 create menu 2 ... } which would create the items each frame, and destroy them at the end of the frame. This is not how I implemented it. I have something more in the lines of: init() { menubar = create_menubar() menu1 = create_menu(menubar, ....) menu2 = create_menu(menubar, ....) } render_frame() { render_menubar(menubar) } where render_menubar will actually render the menubar and it's children, which are the menu options. It will draw the menu bar background, will draw each menu option itself on the menubar according to it's state. If the menu in the menubar it is not with cursor over, then goes to the next menu in the menubar and renders it. If the cursor is over the menu then one of the previous frames already set it's state to hovered (this is something tricky to accommodate with, but we're re-rendering the entire GUI each frame, from 0), so we know we should render it in different color. Also, we know that in this case we also render it's menu items, because in my case the menu will automatically display it's menu items. Your case may vary, you might opt for adding a different state and show the menu options only if menu in the menu bar is clicked. The same process goes for menu items which are hovered/clicked , except I keep track of which menu item in any of the submenus is hovered, so I can draw the entire menu submenu tree open. (this is the case when one hovers to a menu on menubar then one of the menu items which opens a submenu then one of the sub menu items which opens another submenu ...) I hope it makes sense. The trickiest part is to acknowledge that the rendering is done each frame, so for example you can set up a widget state and you don't have to redraw it, since it will happen anyway on the next render. For example if you draw the menu bar and then detect one of the menu items in the menu bar has mouse over, in this case (since everything is re-rendered each frame) you can simply set the flag that menu item is hovered. Since the widgets and their state is persistent between the frames, the next render will just pick up the new state and render the menu item correctly. I hope it helps.

The code there is just a sample. In my case I have a C++ hierarchy of objects and each widget takes care of rendering itself. I just thought something simpler would be easier to understand.

@@jancsifarkas5164 Hi, sorry if i bother you again, i can't figure out how it creates the mouse hover event when i hover over widgets. I've created the click event so far.

I've fixed the description. Thank you!

Sorry I don't have the code anymore, it was long time ago, but it was pretty much using STM32 Standard Peripheral Libraries (stdperihp) and FatFs, and the SD card was accessed with over the SPI interface. The video was composed from rgb frames saved uncompressed, a conversion made with ffmpeg if I recall correctly.