Add block list for intel hex and motorola srec
TEST: Load various hex and srec files
- Test search capability
- Test jump to section
### Problem description
The intel-hex/motorola formats can be loaded but not quite ideally,
including there is no list of segments/blocks that
can be extracted from file layout (metadata).
### Implementation description
I implemented similar feature as process monitor provider does, to
extract chunks while parsing the file and show
them as a sidebar list
### Screenshots
Looks like this:
<img width="1893" height="897" alt="image"
src="https://github.com/user-attachments/assets/c37d46cb-d129-4f9a-bb9a-d8969f397c6e"
/>
### Additional things
There are some improvements that could be made:
1. There is currently no API to jump to address, which would be useful
to jump to beginning of a hex/srec segment.
2. When jumping with setSelection, jumping backwards makes the first
visible line the jump address/line, however, when jumping forward, the
jump address is at the bottom (see image).
3. Unsure about convention for searches, should we search elements as
startsWith given user string, or contains or including 0x prefix or not,
whether to keep prefix zeros since the region size is 8 bytes, but
addresses should be <= 32 bits, etc.
### Problem description
This PR addresses issue #2013 that described a cluttered Event Manager.
This is a DX issue and should not impact the users whatsoever.
### Implementation description
The changes revolve around three main points:
1. the Event Manager (`event_manager.hpp`) was split into four
categories: GUI, Interaction, Lifecycle, and Provider, and two types:
Events, and Requests. This results in the following files:
- `events_gui.hpp`
- `events_interaction.hpp`
- `events_lifecycle.hpp`
- `events_provider.hpp`
- `requests_gui.hpp`
- `requests_interaction.hpp`
- `requests_lifecycle.hpp`
- `requests_provider.hpp`
2. Every event and request now has its own piece of documentation, with
a `@brief`, accompanied by a longer comment if needed, and gets its
`@param`s described.
3. The old `event_manager.hpp` import was removed and replaced by the
correct imports wherever needed, as to reduce spread of those files only
to where they are truly useful.
### Additional things
The commits have been split into (chrono-)logical steps:
- `feat`: split the Event Manager, and replace the imports
- `refactor`, `chore`: make various small changes to match the required
structure
- `docs`: add documentation for events and requests
Hopefully, this will help to review the PR.
*Note: Beware of very long rebuild times in between the commits, use
them sparingly! The Actions will ensure this PR builds anyways*
Closes#2013
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Co-authored-by: Nik <werwolv98@gmail.com>
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
This PR aims to address #1645 that caused the built in file provider's
change monitor to trigger the notification popup dialog multiple times
in a row after multiple external file changes.
### Implementation description
I added an additional boolean field
`m_changeEventAcknowledgementPending` that tracks whether there are any
pending or unacknowledged change notification dialogs to prevent further
dialogs from being opened. The flag is only reset to its initial value
once the user has acknowledged the first `PopupQuestion` dialog.
Since the file is reloaded only after the user clicks 'Yes', it is
unnecessary to ensure that only the latest popup is acknowledged.
This pull request fixes build on FreeBSD. The changes are conditioned
with `#if defined(__FreeBSD__)` preprocessor macro and they should not
affect build for other operating systems.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
Co-authored-by: iTrooz <hey@itrooz.fr>
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
Implement a Linux backend for the ProcessMemoryProvider plugin.
### Implementation description
<!-- Explain what you did to correct the problem -->
Most of the provider code is the same between Windows and Linux. The
primary differences are:
- enumerate PIDs in `/proc/` to get the process list
- use `/proc/<PID>/cmdline` as the process name
- parse `/proc/<PID>/maps` to get the module list
- reading/writing from memory is done using
`process_vm_readv`/`process_vm_writev`
NOTE: `sudo setcap CAP_SYS_PTRACE=+eip build/imhex` must be run to give
the binary permission to read another process' memory. Running as root
user should also work but I would not recommend it.
### Additional things
The existing translations keys no longer match since I moved the plugin
from `windows` to `builtin`.
I'm not well versed in C++ so I attempted to keep my changes rather
simple. Feedback is very welcome.
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
