diff options
| author | Andrew Burgess <aburgess@redhat.com> | 2026-02-22 11:16:15 +0000 |
|---|---|---|
| committer | Andrew Burgess <aburgess@redhat.com> | 2026-03-05 09:42:18 +0000 |
| commit | ee89a3c9eff5aa2d1345a1a1b258e3ed87945ed2 (patch) | |
| tree | 6e9f6227d57df2d7c7e3f7789fefa6f1a5aa2540 /sim/testsuite/lib | |
| parent | 602c91f4d1b01b76f559450d216846d0c1c599fb (diff) | |
| download | gdb-master.zip gdb-master.tar.gz gdb-master.tar.bz2 | |
This commit introduces a new Python event, selected_context. This
event is attached to the user_selected_context_changed observer, which
triggers when the user changes the currently selected inferior,
thread, or frame.
Adding this event allows a Python extension to update in response to
user driven changes without having to poll the state from a
before_prompt hook, which is what I currently do to achieve the same
results.
I did consider splitting the user_selected_context_changed observer
into 3 separate Python events, inferior_changed, thread_changed, and
frame_changed, but I couldn't see any significant advantage to doing
this, so in the end I went with just a single event, and the event
object contains the inferior, thread, and frame.
Additionally, the user isn't informed about which aspect of the
context changed. That is, every event carries the inferior, thread,
and frame, so an event triggered when switching frames will looks
identical to an event triggered when switching inferiors. If the user
wants to know what changed then they will have to track the current
state themselves, and then compare the event state to the stored
current state. In many cases though I suspect that just being told
something changed, and then updating everything will be sufficient,
which is why I've not bothered trying to inform the user what changed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24482
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'sim/testsuite/lib')
0 files changed, 0 insertions, 0 deletions
