Add global widget switch history on seek change

[andersendsa]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've updated the documentation with the relevant information (if needed)
• I've used AI tools to generate fully or partially these code changes and I'm sure the changes are not copyrighted by somebody else.

Detailed description

This adds a global widget switch history tracked inside MainWindow. When the user seeks backward/forward using the Rizin seek history, MainWindow will attempt to restore the widget type that was active at that history state. A new preference checkbox is added under Preferences -> Interface -> Navigation to enable/disable this feature.

Test plan (required)

1. Open a binary in Cutter.
2. Ensure the "Enable global widget switch history" is turned on by navigating to Edit -> Preferences -> Interface and checking the option under Navigation.
3. Go to the Functions widget and double click on a few different functions to generate seek history.
4. Manually change the active widget for some of those seeks. For instance:

• On the first function, view it in the Graph widget.
• Seek to a second function, and switch to the Hexdump widget.
• Seek to a third function, and view it in the Disassembly widget.

5. Use the Undo Seek button (or shortcut Alt + Left Arrow) to go back in the history.

• Expected Outcome: When going back to the second function, the Hexdump widget should automatically activate. When undoing again to the first function, the Graph widget should automatically activate.

6. Use the Redo Seek button (or shortcut Alt + Right Arrow) to go forward in the history.

• Expected Outcome: The active widgets should be correctly restored to the widgets you selected in step 4 (Hexdump then Disassembly).

7. Go back to Edit -> Preferences -> Interface, uncheck the "Enable global widget switch history" option.
8. Perform additional seeks and undo/redo operations.

• Expected Outcome: The widget type should remain whatever is currently active, without automatically switching based on history.

Closing issues
Closes:#3605

[andersendsa]

Hi @PremadeS could you pls let me know if this pr needs any changes or it is good to merge

[PremadeS]

Haven't check out the code thoroughly yet but just from inital testing there seems to be a slight misjudgement on when to change memory widget when Undoing and Redoing

See this for example:

Initially there is no seek history.
Double clicked on __libc_start_main in graph widget, since there is no graph for it, It auto switches to hexdump widget. But seeking back/undoing shows 0x000020ef in hexdump widget even though it should've been shown in graph because that's where the initial click happened. Seeking forward/redoing correctly shows it in graph widget but seeking back again shows it in hexdump widget making Undo and Redo widget switches inconsistent

[andersendsa]

Haven't check out the code thoroughly yet but just from inital testing there seems to be a slight misjudgement on when to change memory widget when Undoing and Redoing

See this for example:

Initially there is no seek history. Double clicked on `__libc_start_main` in graph widget, since there is no graph for it, It auto switches to hexdump widget. But seeking back/undoing shows `0x000020ef` in hexdump widget even though it should've been shown in graph because that's where the initial click happened. Seeking forward/redoing correctly shows it in graph widget but seeking back again shows it in hexdump widget making Undo and Redo widget switches inconsistent

Hi @PremadeS I have done the changes pls let me know if this pr needs any changes or if it is good to merge

[PremadeS]

Switching between widgets overrides current seek to that widget. From the code it seems intentional but it would be better if the widget changing history was linear in my opinion.

Example:

0- Initially the seek is at "address0" in graph widget without doing anything
1- Seek to "address1" in graph widget
2- Switch to hexdump widget
3- Seek to "address2" in hexdump widget
4- Seek to disassembly widget
5- Seek to "address3" in disassembly widget

Now undoing all seeks does the following:
1- Shows "address2" in disassembly widget
2- Shows "address1" in hexdump widget
3- Shows "address0" in graph widget

should-save-widget.mp4

meaning it overrides the seek when the widget is changed to that specific widget.
It would be better to have another entry for that widget, meaning if user is at "address1" in graph widget and switches to hexdump and seeks to "address2" then undoing should do the following:

1- First undo: shows "address1" in hexdump
2- Second undo: shows "address1" in graph widget
3- Third undo shows "address0" in graph widget

TL;DR: widget switches should also be saved alongside seeks

[andersendsa]

Switching between widgets overrides current seek to that widget. From the code it seems intentional but it would be better if the widget changing history was linear in my opinion.

Example:

0- Initially the seek is at "address0" in graph widget without doing anything 1- Seek to "address1" in graph widget 2- Switch to hexdump widget 3- Seek to "address2" in hexdump widget 4- Seek to disassembly widget 5- Seek to "address3" in disassembly widget

Now undoing all seeks does the following: 1- Shows "address2" in disassembly widget 2- Shows "address1" in hexdump widget 3- Shows "address0" in graph widget

should-save-widget.mp4
meaning it overrides the seek when the widget is changed to that specific widget. It would be better to have another entry for that widget, meaning if user is at "address1" in graph widget and switches to hexdump and seeks to "address2" then undoing should do the following:

1- First undo: shows "address1" in hexdump 2- Second undo: shows "address1" in graph widget 3- Third undo shows "address0" in graph widget

TL;DR: widget switches should also be saved alongside seeks

Thanks for the suggestion @PremadeS will work on it and will revert

[andersendsa]

Hi Sorry I pushed the commit of another pr will revert the changes and work on the issue

[PremadeS]

Hi Sorry I pushed the commit of another pr will revert the changes and work on the issue

No worries

[andersendsa]

Hi @PremadeS I have done the changes pls let me know if the pr needs any changes or if it is good to merge