<!--
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 -->
This PR addresses issue #491 regarding the inability to open ImHex
project files (`.hexproj`) directly from various UNIX Desktop
Environments.
_NB: This PR's scope is limited to UNIX systems, as I have no access to
MacOS systems and could not find a way to automatically create file
associations on Windows._
### Implementation description
<!-- Explain what you did to correct the problem -->
In order for project files to be recognised as such, we need to create a
new MIME type. According to [RFC 6838 section
3.2](https://www.rfc-editor.org/rfc/rfc6838#section-3.2), additional
application MIME types should be defined with a vendor prefix.
_NB: This is preferred over the deprecated `x-` prefix, although RFC
6838 states that the vendor should be "a well known producer"_
This PR proposes a new mime type for ImHex project files:
`application/vnd.imhex.proj`, and associates it with the file format
`*.hexproj`.
It also implements small changes in the Arch Linux and RPM builds, in
order to correctly ship the MIME XML file during installation.
### Additional things
<!-- Anything else you would like to say -->
The implemented change has been manually tested in the following UNIX
systems and graphical environments:
- Arch Linux, with Gnome 47.2
- Arch Linux, with XFCE4
- Fedora 41 Workstation Edition, with Gnome 47.0
- Fedora 41 Plasma, with KDE Plasma 24.08.2
- Ubuntu 22.04.5, with Gnome 42.9
Which tests the functionality of the following build types:
- Arch Linux's `.zst` packages
- Debian `.deb` packages
- RPM packages
For Arch Linux and RPM packages, this has been tested to ensure that
post-installation hooks (such as regeneration of the MIME database) is
correctly executed (which it is). No further changes than those
implemented in the PR are needed.
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Fixes
[https://github.com/WerWolv/ImHex/security/code-scanning/223](https://github.com/WerWolv/ImHex/security/code-scanning/223)
To fix the problem, we need to ensure that the multiplication is
performed using a larger integer type to avoid overflow. This can be
achieved by casting one of the operands to `u64` before performing the
multiplication. This way, the multiplication will be done in the larger
type, preventing overflow.
We will modify the line `index += frameCount *
device->playback.channels;` to cast `frameCount` to `u64` before the
multiplication.
_Suggested fixes powered by Copilot Autofix. Review carefully before
merging._
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Even if focus is given to the pattern editor the cursor will not show
until the editor contains printable chars.
### Problem description
I was using the wrong condition to enter the loop that skipped the
default empty document.
### Implementation description
The fix was to check if there are lines of text that need to be
processed even if they are empty.
Even tough the sound visualizer has `channels` as one of its parameters
it wasn't using it properly.
### Problem description
The biggest problem is that at each frame the index was being advanced
per channel frame_count increments. The number of channels also
determines how many graph will be needed to display the graphs of the
visualized sound files. Besides these two problems there were many
others like incorrect playback time, cracking audio, etc. which will not
be mentioned.
### Implementation description
To sample the signal a channel sampler was created based on the one used
previously that returns as many sampled signals as there are channels.
This PR aims hopefully at fixing all the problems encountered, and it
has been tested extensively using `Audacity` exported samples to ensure
the visualizer fidelity on playback and graph appearance.
### Screenshots
### 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.
### Problem description
Previous implementation ignored everything after the first newline.
Other changes include:
- Added isEmpty() function that checks if editor has no content.
- replaced asserts with default behavior to avoid unneeded crashes.
- fixed off by one error in DeleteRange()
- some crashes occurred because readily available corrective actions
were not being taken. For example start/end being -1 in DeleteRange().
- At the heart of search/replace is the ability to translate from
indices into the text string to line/column coordinates used for
everything. To this end a function (StringIndexToCoordinates) was added
to do the translation taking utf-8 chars into account. This made the
recently added Utf8BytesToChars function unneeded, so it was removed.
- Removed commented out code that is not useful anymore. Also removed
tooltip code which is also unused.
- Removed unused parameter wrapAround to FindNext().
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.
### Problem description
Loading a file on the command line or using the context menu in windows
was triggering an achievement before the achievements file was loaded.
This resulted on the achievements.json file to be overwritten with all
the achievements reset except for the one to open files.
### Implementation description
This PR fixes the problem by introducing a boolean that is used to check
if the file has been loaded.
---------
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
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
seem to fix#1809. I couldn't build the app, so hoping that's the right
place to update resulting `Info.plist`
### Implementation description
<!-- Explain what you did to correct the problem -->
### Screenshots
<!-- If your change is visual, take a screenshot showing it. Ideally,
make before/after sceenshots -->
### Additional things
<!-- Anything else you would like to say -->
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.
std::forward ensures that the arguments are perfectly forwarded to
loadScript
By reserving space in the features vector based on the size of scripts,
we can avoid multiple memory allocations during the loop. If an
exception occurs, returning an empty vector immediately clarifies that
no scripts were loaded. Without reservation, each call to emplace_back
could potentially trigger a reallocation if the current capacity is
exceeded, which is costly in terms of performance. This leads to more
efficient memory management and can significantly speed up the execution
time when dealing with a large number of scripts.
### 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 only time textures would update was through the file picker. Once UV
coordinates were used, disabling them didn't have any effect because the
vertex array didn't invalidate the corresponding buffer array. When
`shouldUpdate` is true, the light source needs to know as well,
otherwise it will set the location at 0,0.
### Implementation description
Textures were fixed by creating a member variable that holds the file
name of the texture used in the last model rendering.
Instead of invalidating buffer arrays it is much simpler to define a
default UV coordinate set for the case when no UV is specified. if a
texture is not present then the values of UV will not be used. If there
is a texture it must be a minimum of 1 pixel in size. So we choose the
UV coordinates so that every vertex gets assigned the color at the 0,0
coordinate of the texture.
When `shouldUpdate` is on, we also turn `shouldUpdateLightSource` on.
Also included are some formatting changes that are purely aesthetic.
---------
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>
