Closed ahmadaal closed 2 weeks ago
@ppizarror , have any thoughts? :)
I also wonder if I may just be doing something wrong with how I set up the menu hierarchy...
Hi, I Added a new version of 4.4.8that adds the
remember_selection`` to the Menu constructor. I used the same philosophy as discussed here. Thanks, and I'm sorry for the delay in finding a solution.
Environment information Describe your environment information, such as:
Describe the bug When you have a nested menu structure that is more than one level deep, the parent menu "forgets" which widget was selected before you navigated into a submenu. This means that when you navigate back to the parent, the 0th widget is always selected. This creates a usability issue because the user's selection is not remembered.
To Reproduce Run the sample code here. This has 2 levels of nesting, and has some extra buttons so that the bug doesn't get hidden because the 0th button itself is the one that should be "remembered" :)
To trigger the bug, press "Sub", and then press "Sub2". Then navigate back by either pressing the "Back" button, or F1. You will see that instead of the selection of the "Sub2" button being remembered, the selection has reset to the "Back" button. I would expect it not to reset like this.
Note that doing only one level of navigation does NOT trigger this bug. Meaning, if you simply press "Sub" and then go back to the root menu, the selection is remembered. I believe this because for the root menu only,
self._top == self
.Expected behavior When I navigate into a submenu, and then navigate back out to to the parent, the parent should always remember which widget was selected before the navigation took place.
Additional context I suspect this bug may be because of this line in
_open()
inmenu.py:3556
:self._current._select(0, 1, SELECT_OPEN, False, update_mouse_position=False)
I won't speculate too much about the purpose of this line of code since I'm not very familiar with the codebase, but if I hack this and change it toself._top._current._select(...)
it does seem to fix the issue. I don't know if that's the correct fix though.It seems that the lines right before attempt to change the current menu to be the one that is about to be opened by doing:
but does the following
_select()
call onself._current
(vsself._top._current
or evenmenu._current
), which is still the parent menu, thus selecting the 0th widget of the parent menu before opening the child.And in the root case,
self._top == self
. Thus settingself._top._current
actually setsself._current
. Thusself._current
IS actually the submenu (not the parent), and thus the submenu is the one who's widget index gets reset.