### 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>
Fixes https://github.com/WerWolv/ImHex/issues/1807
### Problem description
Build fails for MacOS x86-64 due to using a wrong architecture header.
### Implementation description
Used the headers for mach that auto select the correct architecture.
### Additional things
This is being used in https://github.com/NixOS/nixpkgs/pull/330303 as a
patch
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
The process memory provider currently doesn't function correctly on
Linux due to incorrect handling of the special procfs file
`/proc/<pid>/maps`. I don't know if some of this behavior could vary by
distro and/or kernel version, but I've observed the following issues in
my Ubuntu 24.04 environment.
- The current code in master calls `file.readString()` which attempts to
determine the size of the file by [seeking to the
end](https://github.com/WerWolv/libwolv/blob/master/libs/io/source/io/file_unix.cpp#L148).
However, procfs files don't have a defined size, so this fails with a
return of -1. libwolv [interprets this as the file size and attempts to
allocate an enormous
buffer](https://github.com/WerWolv/libwolv/blob/master/libs/io/source/io/file.cpp#L30),
which results in an exception, so ultimately the process memory provider
is unusable on the current code.
- The previous version of the code that went out in 1.35.4 was calling
`readString` with a fixed maximum size of `0xF'FFFF`. This avoids the
seek issue, but when working with special files, a single `read` call
isn't guaranteed to read the requested number of bytes even if that many
bytes are available. In practice, on my machine, this call only ever
reads the first few dozen lines of the file. So the feature works in
this version, but it's unable to see the vast majority of the process'
address space.
- On a more minor note, on rows in the `maps` file that have a filename,
the filenames are visually aligned by padding spaces between the inode
column and filename column. ImHex includes these spaces as part of the
filename, resulting in most of the path being pushed out of the visible
area of the window.
### Implementation description
- To ensure the entire `maps` file is read, I've changed the code to
read from the file in a loop until we stop getting data. I've also set a
fixed limit on the maximum number of bytes to read in one go to avoid
issues with trying to determine the file size.
- I've added a `trim` call to remove any padding around the filename.
### Screenshots
Exception in `file.readString()` in current code (for some reason this
also causes the window to become transparent):
Abridged memory region list in 1.35.4:
Complete memory region list after this PR:
### Additional things
I was focused on fixing this ImHex feature here, but I wonder if some of
this should be addressed in libwolv. Maybe `readBuffer` in file_unix.cpp
should read in a loop until it has the requested number of bytes or
encounters EOF/error?
---------
Co-authored-by: Justus Garbe <55301990+jumanji144@users.noreply.github.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>
