If you project has two patterns and one is very big, switching providers
while the big file is being highlighted makes the small one skip its own
coloring. The error was caused by a failure to interrupt the ongoing
lengthy highlighting process in a timely manner. It appears that calling
task interrupt allows the task to run to completion and when the task
runs to completion then the retrying mechanism is not trigger and the
small pattern never has a task assigned for coloring.
This was fixed by creating a variable that signals the intention to
interrupt the current highlighting process. The most used function in
the highlighter (used to update the current token) checks the variable
and throws an out of range exception causing the interruption of the
current highlighter and triggering the retry mechanic.
Reorganized source code into files named in the fashion of imhex and
split large functions into smaller ones. Moved all function definitions
out of the header except for one-liners. All variable types were
switched to use imHex standard (u8,...) and removed duplicated functions
that were needed when the text editor was isolated.
Minor improvements to find/replace while making sure they still worked
with utf-8 chars.
### Problem description
In current Chinese translation, "Windows context menu entry" in General
settings has been tranlated to 窗口上下文菜单项. and for Traditional Chinese,
it's 視窗內容功能表項目 (basically the same).
The previous translations were not conveying the correct meaning
associated with the term "Windows context menu entry". They were too
literal and did not clearly describe the functionality related to the
Windows Explorer context menu.
"窗口" in Chinese means a physical window, **not the Microsoft Windows
OS**. The Windows OS is usually referred to as "微软视窗" (rare) or left as
"Windows".
"上下文菜单" is a very "direct" translation of "Context menu" that is hard to
understand for most users. Chinese user usually call it "右键菜单", which is
"Right-Click Menu".
### Implementation description
I've changed it to 添加到文件资源管理器右键菜单 for Simplified Chinese, and
加至檔案總管的環境選單 for Tranditional Chinese.
### Problem description
Messages in the TCP tool were only visible as a text string in the
messages list and unable to be opened in the hex view.
There was also no way to send data other than as a typed in text string
in the input field.
### Implementation description
* Added the ability to double-click on a message in the messages list to
open it in a provider tab.
* Added a new button to the client tab to send the current provider to
the connected server.
* Updated the list look to show the message index in a column
### Screenshots
https://github.com/user-attachments/assets/198d78c7-7c94-4f48-ac8c-3581e2ac12e4
---------
Co-authored-by: Nik <werwolv98@gmail.com>
This PR improves the safety and reliability of the deleteOldFiles()
function by:
Preventing symlink attacks
Uses std::filesystem::canonical() to resolve all paths, eliminating ./..
and symlinks
Verifies each file is actually inside the target directory before
deletion
Safer file operations
Explicitly skips non-regular files (directories/symlinks)
---------
Co-authored-by: Nik <werwolv98@gmail.com>
This PR implements a neat little feature I missed - the ability to jump
to the next/previous differing byte, skipping the chunk of repeating
bytes. Very useful when you analyze a raw flash dump and want to skip
the large sections of `0x00`s/`0xFF`s.
Some implementation details worth validating:
- I wasn't sure what is the correct place to put the new menu entries
into. The possible candidates were `File -> Go to address...` and `Edit
-> Follow selection`. I chose the former, although the latter may be a
better fit since it already states that the action is related to the
selection. Overall, it may be a good moment to refine these menu entries
in general.
- I didn't add any tests since I'm not sure what is the project's policy
for those. Please let me know if I need to add some!
- I added the machine-generated translations for the new menu entries
which may be considered a questionable thing. Please let me know if
you're unhappy with those, I'll drop the commit.
Also, thanks for such a nice tool, I use it a lot and was glad to build
a new feature for it!
With an initial Window size of 1 by 1, the program aborts during launch
on my Debian 12 (bookworm) system running the Mate Desktop environment
on X11.
The exception from X is the following:
```
$ ./imhex
[18:36:33] [INFO] [main | Main] Welcome to ImHex 1.38.0.WIP!
[18:36:33] [INFO] [main | Main] Compiled using commit master@59c6d30
[18:36:33] [INFO] [main | Main] Running on Linux 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) (x86_64)
[18:36:33] [INFO] [main | Main] Linux distribution: Debian GNU/Linux 12 (bookworm). Version: 12
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Resource id in failed request: 0x5400009
Serial number of failed request: 152
Current serial number in output stream: 163
```
The culprit is in `hex::init::WindowSplash::initGLFW()`, specifically
the `glfwCreateWindow` call with a window size of 1 by 1, that's the
last call in the ImHex codebase, after that it's libglfw and libX11.
The issue can be worked around by inhibiting the splash screen using the
`IMHEX_SKIP_SPLASH_SCREEN=1` environment variable, setting the window to
be a size larger than 1 by 1 also seems to resolve the situation.
My hunch is that an underflow occurs somewhere with the smaller values,
but I did no further investigation into analysing the root cause.
----
Above the line is the commit message.
### Problem description
See https://github.com/WerWolv/ImHex/issues/2215, which I think is the
same problem, and commit description above. Edit; I did another search
in the issues, I wouldn't be surprised if #2233 is a duplicate of the
2215 issue.
### Implementation description
Please see the commit message.
Analysis was done by setting an X11 error handler, making that throw and
running it in a debugger. This is available in this dev commit;
4a24e16a2ef100a9417e572f6b16c4a95711e94e.
### Screenshots
No apparent glitches if I make the splash window stick around with
`return std::nullopt;` in the `loop()` function. I don't know if there's
an issue at the beginning, but given that the window is set to
transparent before it is created and resized I don't expect any.
Here's a compulsory screenshot of the splash screen over an editor;
<img width="1247" height="666" alt="image"
src="https://github.com/user-attachments/assets/8ce05565-f207-4134-892d-9c074c4c840c"
/>
### Additional things
> Anything else you would like to say
Yes! I don't use ImHex often, but it's really useful when I do, thank
you!
