Feature description
This pull request introduces full Polish language support to ImHex.
It is a new feature that allows users to switch the UI to Polish,
improving accessibility for Polish-speaking users.
Implementation description
-Translated a total of 10 JSON language files into Polish (pl_PL.json)
-All translations were done manually, with the help of tools such as
DeepL, large language models (LLMs), and technical dictionaries
-Validated the JSON files using [jsonlint.com](https://jsonlint.com/)
-Performed initial UI testing — all translated strings appear and render
correctly
Screenshots
Below is an example of the UI in Polish:
Additional things
-I'm a beginner with both ImHex and English, so I may have missed some
things
-I'm fully open to any suggestions or corrections — whether related to
translation accuracy or JSON formatting/style
-I would greatly appreciate it if the reviewer could:
-Confirm that the project still compiles correctly (it built fine on my
side using ninja)
-Check that the pl_PL.json files are properly formatted and follow the
project's standards
If there are preferred tools or workflows for validating and formatting
JSON in this repository, I’d be happy to adopt them in the future.
---------
Co-authored-by: paxcut <53811119+paxcut@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
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
Updated
[plugins/builtin/romfs/lang/zh_CN.json](https://github.com/only9464/ImHex/blob/master/plugins/builtin/romfs/lang/zh_CN.json)
file to add support for Chinese language
### Implementation description
<!-- Explain what you did to correct the problem -->
Updated
[plugins/builtin/romfs/lang/zh_CN.json](https://github.com/only9464/ImHex/blob/master/plugins/builtin/romfs/lang/zh_CN.json)
<br/>The original
file:[plugins/builtin/romfs/lang/zh_CN.json](https://github.com/WerWolv/ImHex/blob/master/plugins/builtin/romfs/lang/zh_CN.json)
### 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 -->
Nothing
### Problem description
While working with the section view, I noticed the window wasn't
resizable.
### Implementation description
This simply removes the `ImGuiWindowFlags_NoResize` flag, and then when
drawing the section window sets the hex editor to 70% of the available
window, leaving 30% to the pattern data. This is not ideal, but I think
before a full rewrite of the section window system this would probably
be a simple change to make it a lot more usable.
### Screenshots
Co-authored-by: paxcut <53811119+paxcut@users.noreply.github.com>
A while back there were some changes to the pattern language library
that changed the way shared_pointers are created using
shared_from_this(). Unfortunatelly the changes were not complete and
various bugs were created among them 2234, json type not working, unable
to export files, static arrays of bitfields,... The cause of the errors
was that in class Pattern the member m_parent was left as a raw pointer
and it needs to be handled by shared pointers. Also there were some
cases in which share pointers were needed but unique pointers were used
instead. Both cause crashes when shared_from_this is used on pointers
that are not managed by shared_ptr. Another source of errors were
infinite loops of clone and reference that caused stack overflow. The
fixes include making m_parent a weak pointer, turning unique pointers
into shared pointers and moving codefrom the copy constructors into
clone to break the infinite loops.These changes are the bare minimum
needed to bring the pattern language back to the full functionality that
it had before shared_from_this was introduced or at least thats the
hope.
This pr aims at fixing for negative values in advanced search for
numerical values. For a simple example try searching for -1 for int32_t
which is 0xFFFFFFFF. With the changes you can now find -1 for 1,2,4 or 8
byte integers.
Internal types are bigger than or equal to the types selected in the
options. Search keys are converted to the bigger type, but the values
read from the input file are not. This works ok for positive numbers,
but for negatives it needs some casting.
The casting is performed inside a newly added function that takes the
value returned by read, the size in bytes of the selected type in the
options and a template argument for the 64 bit type the value is stored
into.
I have tested positive and negative values for several different sizes
of signed integers. Also tested unsigned integers both in the low range
(near lowest limit) and in the high range (near largest possible value
for that type)
<!--
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 is a fix for the ImHex bug "ImHex crashes when analysing any PE
file #2221"
### Implementation description
This is a fix for the ImHex bug "ImHex crashes when analysing any PE
file #2221". The fix requires changes to the Pattern Language and the
ImHex UI. Revision would be wise. We want to avoid collateral damage.
It's a big code base and I'm new to it and the compilers/build-systems
used. And the bug is complex and low-level. I suspect this will fix
other random crashes. The problem is caused by two issues:
- The std::sort algorithm conjuring up garbage due to the sorting
criteria not being a strict weak ordering. See
[this](https://github.com/Voultapher/sort-research-rs/blob/main/writeup/sort_safety/text.md)
link.
- We sort shared_ptr<ptrn::Pattern> by pointer value, and the
object is a clone. In essence we're changing the values as we're
sorting.
Fixes#2221
### IMPORTANT
I'm not sure how "plugins/builtin/source/content/data_formatters.cpp"
got into the PR. Been trying for an hour to rectify. I'm not a Git
expert (the last time I used source control seriously SourceSafe was a
thing) please ignore that file. It's a fix for another PR I submitted. I
suspect I stuffed up the branching and merging.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
The recent update that made importing patterns undoable had the side
effect of undoing tab changes as well. When working on a fix for that it
became clear that the undo/redo stacks were being shared by all
providers so that you could undo changes done in a separate file. The
problem was fixed by making the text editors (and the console editors as
well) to be per provider which gives better control on things like
breakpoints and selections and a more robust focusing system that
preserves the cursor positions and removes the need to click on a
pattern to start editing. There are a lot of changes, but they are
mostly all the uses of text editors being now coded differently to
manage the providers. File imports are still undoable, but switching
providers is not.
Further changes suggested by reviewer were implemented namely a mull provider was being used and there was a get function missing which prevented the use of the preferred syntax.
The recent changes to the text editor to fix the longest line length
problems broke the console horizontal scrollbar. The code that displays
the console editor was more complicated that it needed be, and it had
the bad side effect of resetting the cursor which prevented horizontal
scrolling. Adding a function that appends lines to the text editor fixes
all problems and makes the code clearer. To accommodate for strings
containing zeros, the code that inserts text was changed to print a '.'
when zeros are encountered thus keeping the line length the same.
Proof of concept for implementing subpixel processing in ImGui. This is
work in progress, and it is bound to have problems.
What it does:
1) Uses freetype own subpixel processing implementation to build a
32-bit color atlas for the default font only (no icons, no unifont) . 2)
Avoids pixel perfect font conversion when possible. 3) Self contained,
no ImGui source code changes.
4) Results in much improved legibility of fonts rendered on low dpi LCD
screens that use horizontal RGB pixel layouts (no BRG or OLED or CRT if
they even exist anymore)
What it doesn't:
1) Fancy class based interface. The code is barely the minimum needed to
show it can work. 2) Dual source color blending. That needs to be
implemented in shader code, so it needs to change ImGui source code
although minimally. This will result in some characters appearing dimmer
than others. Easily fixed with small fragment and vertex shaders. 3)
subpixel positioning. If characters are very thin they will look
colored, or they can be moved to improve legibility. 4) deal with
detection of fringe cases including rare pixel layouts, non LCD screens,
Mac-OS not handling subpixel rendering and any other deviation from the
standard LCD. 5) tries to be efficient in speed or memory use. Font
Atlases will be 4 times the size they were before, but there are no
noticeable delays in font loading in the examples I have tried.
Any comments and code improvements are welcome.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
This was caused by the variable that holds the bar location not being
updated when window was resized.
The bar can be moved until only one line is shown in the smaller window.
When ImJex window is resized, the proportion of editor/console height is
maintained.
