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!
Where one door opens, another one closes (said someone) and in this
situation i mean view, because there's no event for closing a view only
opening one, so please add this :c
### Problem description
Simply adds an **EventViewClosed** to match the pre-existing
**EventViewOpened**. Also fixes the issue where EventViewOpened wouldn't
trigger for windows that were popups (even if they are technically a
View.
### Implementation description
I mirrored the current functionality of EventViewOpened for closing.
---------
Co-authored-by: paxcut <53811119+paxcut@users.noreply.github.com>
allows the ability to assign colors to global placed and non-placed
variables, pattern, local and calculated pointer variables, template
arguments, function variables and arguments, etc etc etc. It
accomplishes this using the parser and the token sequence generated by
the lexer. It still uses the original colorizing code but the underlying
data holding the pattern has been updated to be easier to use and to
debug. The changes are too numerous to cite here.It is a big but
necessary step to bring the pattern editor to a somewhat useful state.
There may be one commit in the pattern language repo needed to be able
to run this code
MSVC build failing because of a warning treated as an error for
variables being used without initializing even though they are being
passed as references.
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>
