### Problem description
As suggested in #1904, ImHex could benefit from having the capability of
pasting text directly into the editor.
This also complements the "Copy as... ASCII string" capability already
implemented in the software.
### Implementation description
A new shortcut called `Paste all as string` (to resemble the naming of
the `ASCII string` copy option) now allows to paste plaintext directly.
This shortcut is mapped to the `CTRL + ALT + SHIFT + V` keybind.
Internally, a new flag called `asPlainText` has been added to the
`pasteBytes` function, to minimise code changes and streamline code
readability.
The buffer is a simple type cast of the clipboard, without any
modification applied, which is then handed to the provider's `write`
function.
### Screenshots
The new shortcut is visible in the menu, just below the other paste
options:
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Since the popup is fairly small I opted for a straight addition parallel
to the find/replace. To make code more clear the functions that create
each popup were coalesced and made their interface simpler. That forced
a reorganization of the data processing which translates to a larger
number of changes than usual. Most of those changes are just moving some
action from one function to another.
The old method to identify popups using the size and position of the
window was dropped in favor of one based on child windows and using
their names for a much easier and robust identification.
Added specialized functions to text editor to jump to a line or to given
coordinates with a simple interface that simplifies older code that
performed the same task.
Because this PR modifies heavily the same code as the previous PR (1983)
it is also included here to make merging easier.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
Errors printed in the console can be clicked to have the cursor jump to
the source code line where the error is at.
The mouse cursor changes its shape to indicate which parts of the error
message can be clicked on the console. When the cursor jumps, the text
editor takes the focus away from the console and it scrolls the window
to make the line with the error is visible if it isn't. This code uses
the function created for the go-to PR but adds code to switch focus to
the target. When the codes are merged please keep both the part that
jumps the cursor and the part that sets the focus.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
As described in #1846:
- the `Edit the Hex` achievement doesn't unlock when it should
- the `ROM Hacks` achievement is not using event-driven architecture
(the functions call `unlockAchievement` themselves)
### Implementation description
Firstly, for the `Edit the Hex` achievement:
- replaced the old event listener on `EventPatchCreated` with a listener
on `EventProviderDataModified`, which picks up bytes changes
- ensured the provider data change comes from a File provider, else
unlocking the achievement wouldn't make sense
- *Note*: a discovered side effect is that the "Fill" function modifies
the provider byte per byte (with a for loop)
- there is no use in testing the size of the data change, as it is
always 1 byte
- the Fill function could probably be reworked to fill in whole regions
at a time?
About the `ROM Hacks` achievement:
- implemented the new, still unused `EventPatchCreated` event.
- signal signature is `const unsigned char *, u64, const IPSKind`:
buffer pointer, buffer size, and IPS kind (IPS/IPS32)
- make use of the `::post` and `::subscribe` methods on said event to
unlock the achievement
- **WARNING::behaviour change**: the event's `post` signal has been
moved in the success branch of the IPS generation condition, meaning
that achievement will only unlock if IPS patch export has worked. I felt
it would make more sense than unlocking an achievement on an error, if
there was any to raise.
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Fix the AES ECB mode in the data processor along with some other misc
fixes:
- Fixed nullpointer node not working
- Fixed crypto module incorrectly using mbedtls api
- Fixed crypto module ignoring mbedtls errors
- Fixed silently ignoring of errors in AES node
Some context menu entries that were available as shortcuts were greyed
out. This PR aims to fix them and improve how context menus work for the
text editor and the console. The improvements include:
- automatic focus on right click
- automatic selection on right click. If selected text is right-clicked
then copy, cut and find will use the selection, if no selection is
clicked but there is text were right-clicked, then the word will be
selected and used. If right-clicking empty space copy and cut will be
greyed out and find will start empty.
- similar functionality now exists for the console as well except the
menu has fewer options due to it being read-only.
- added esc to close console context menu
### Problem description
At the moment, attempting to edit files using HexII data visualization
is impossible as the editing fields only allow numeric characters but is
interpreted as a hex value
### Implementation description
I yoinked the params used for the hex visualization edit field.
### Screenshots
### Additional things
Ideally this should instead accept the format used by HexII, but I have
what scientists describe as a skill issue and this at least makes it
possible to use HexII without switching back to hex for editing.
### Problem description
This PR aims at making inline visualizers work on the data inspector so
that more rgb encodings can be added as custom pattern language
inspector rows. This was never setup to work because the inline
visualizer rendering function was a private member function.
### Implementation description
In order to be accessible from the inspector class the rendering
function was made public.
### Additional things
Missing still is the tooltip to make it behave like other color entries.
WARNING: this PR won't compile unless [PR 132 from pattern language
repository](https://github.com/WerWolv/PatternLanguage/pull/132) is
merged first. Some changes here are shared by at least another PR to
this repository but there should not be any conflicts as the shared
changes are identical.
### Problem description
fix: Editing patterns with breakpoints sets behaves unexpectedly. As a
simple example, set a breakpoint and insert a blank line somewhere
before the breakpoint location. The breakpoint will appear to move but
in reality it hasn't. To see this set another breakpoint elsewhere in
the file and the old one will be displayed where it is really located
at.
The reason for this and many other problems with breakpoints is that
currently ImHex keeps two set of breakpoints in text editor and in
evaluator that are independent of each other, ie, changes to one don't
affect the other. This PR aims at synchronizing the two sets through the
per provider breakpoints that exist in view pattern editor.
### Implementation description
It accomplishes this by making the text editor version of breakpoints
the principal source of vectors and the ones in evaluator the effective
version. The first allows one to modify the text around and at the
breakpoint and notify others that the changes have induced changes in
the breakpoint locations. The effective breakpoints allow the insertion
and deletion of breakpoints.
View pattern editor is where breakpoints are updated. It receives
notifications from text editor about changes and then makes sure the
version in evaluator is updated with those changes. View pattern editor
also manages breakpoint addition and deletion so before making changes
it gets a copy of the current ones from text editor, sets the ones in
evaluator, uses the evaluator functions to add or delete breakpoints and
finally sets the text editor version with the new version.
This code fixes issue #1950 This PR depends on PR [#27
](https://github.com/WerWolv/libwolv/pull/27) on libwolv repo
### Problem description
See description of the problem on the issue linked above
### Implementation description
The code in the PR uses function added to the libwolv repository to
remove tabs if they exist on the provider. Additionally, any pasted tab
on the pattern editor will be translated to spaces automatically. This
code was tested successfully using the pattern posted in the issue.
### Problem description
fix: pressing F5 (start pattern execution ) while being in a break point
hangs ImHex.
The reason for hanging ImHex was that the shortcut procedure was not
checking if the pattern was already running, and it attempted to start
another one. This makes ImHex wait indefinitely for a lock to be
released
### Implementation description
To fix the hanging of ImHex we check the runtime for current evaluation
and if detected we stop it. In all cases the evaluation is started
again.
### Problem description
Fixes provided for the following unreported bugs.
- Environment variables are set to be per provider but used as if they
are not. When a project is loaded all the environment variables for each
provider are assigned to the first provider making it impossible to add
new ones to the other providers.
- When switching providers, the text editor selection, the text editor
breakpoints, the console text, the console selection and the console
cursor position of the old provider are being assigned to the new
provider
### Implementation description
This PR aims at fixing both errors by:
- using variable defined to be per provider so that they affect their
provider only when necessary.
- creating new per provider variables and using them so that each
provider has their own console, selections and breakpoints.
In order to support the newly added per provided features new functions
were added to the text processor for selections and breakpoints. All the
new per provider variables are defined and used in view pattern editor.
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
Moving error markers to be underwaved created s couple of errors:
- Markers that were 1 char long and located at the end of the line
didn't show on text editor.
- Markers that had zero length or no stack trace didn't show on text
editor.
### Implementation description
- The first error was caused by an off by one error in the column index.
- There was no implementation for errors that had no location or zero
length. Now errors with no location will be shown at the beginning of
the line where they occur. Errors with zero length will be marked from
their location to the end of the line, therefore, errors with no stack
trace will be marked from the beginning to the end of the line.
### 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>
### Problem description
Currently, the pattern editor does not remember where the cursor is
located in each provider. For example, suppose you have 2 providers in
your project, and you scrolled down to line 200 in the first pattern to
make some changes and remembered that the code you want to insert is in
the second provider. Then you switch to the second provider, look for
the code and find it in line 235. Switch back to the first one, and you
are at the beginning of the file. So you again look for the line to edit
paste it to realize that it needs code a few lines before the place you
found it. You switch to the second provider, and you are at the top
again. This gets annoying very fast.
### Implementation description
This PR ensures that, when you return to the pattern in the editor for
any of the opened providers, the cursor will still be at the same place
it was when you switched to a different one. Each provider pattern saves
its cursor position and returns to it when you switch to that provider.
It does that by creating a PerProvider variable and using it when
providers are first opened to set it to the origin and when switching
providers it first saves the position of the old provider and then loads
and sets the saved position of the new provider.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
Currently when errors are found the entire line where the error occurred
is highlighted and one has to look at the error message in order to find
where the error is located on the line. With this PR the line will no
longer be highlighted and the location of the error will be marked with
an red waved line under the error location. Hovering over the text where
the error occurred produces an error overlay so if several errors occur
on the same line they can all be seen separately.
### Implementation description
The definition of error marker was switched to include column and size
as well as line and message like before.
This change required changing the way view pattern editor draws the
error markers because the errors themselves don't have size information.
Also, a new errorHoverBoxes type was defined to help in the detection of
the floating error messages when error is hovered.
Note that the underwave code depends on having a monospaced. If font is
not monospaced the underwaved text can be short/long or displaced.
### Screenshots
### Problem description
There are some recent issues about Mac keys not configured properly for
the pattern editor. This PR moves all the shortcuts to the shortcut
manager, so they can be edited at will. Even if the key is not
identified correctly it should be possible to use preferred keys for any
action.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
