<!--
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 -->
When starting ImHex on a MacBook model with both integrated and discrete
graphics, it will force the computer to use the discrete graphics card.
This causes increased power usage, meaning the fans will spin up, the
battery will drain faster, etc. This program is not very graphics
intensive, so using the discrete graphics card shouldn't be needed.
### Implementation description
<!-- Explain what you did to correct the problem -->
I changed the
[`GLFW_COCOA_GRAPHICS_SWITCHING`](https://www.glfw.org/docs/latest/window_guide.html#window_hints_osx)
setting in GLFW to not enforce using the discrete graphics.
### 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 -->
My editor is configured to automatically remove trailing whitespace, so
I hope that those whitespace changes are ok
Fixes random .NET plugin crash caused by the console window being freed
on the same process.
### Problem description
Sometimes when launching from the explorer ImHex crashes
### Implementation description
We've implemented a launcher to avoid freeing the std streams, that
generated the bug.
### Screenshots
N/A
### Additional things
Blame windows console subsystem
As requested on Discord, a PR to revert the FPS limiter back to the one
that was used in v1.30.1.
The new FPS limiter seems to be flawed in that it runs at about half the
speed it is supposed to be.
See this illustration:
Left is v1.30.1, right is the new version (without this fix). See how
long it takes to respectively reach 0xE90.
This is not a performance issue, because when you fully unlock the
framerate on the right, it's just as fluent as on the left.
This PR intends to add support for .NET scripts that can extend ImHex's
functionality in a portable and cross-platform way.
---------
Co-authored-by: Justus Garbe <55301990+Nowilltolife@users.noreply.github.com>
This PR it just a hack to fix#1160 , it doesn't solve the underlying
problem.
It fixes the problem because by using execvp() directly, it avoids the
call to `sh` done with `system()`, which has a bug on Ubuntu 22.04 which
makes it i,compatibles with the glibc inside the AppImage.
It doesn't fix the underlying problem because the programs we call
themselves still link to the AppImage's libraries instead of the system
ones.
This PR fixes some things about crash handling:
- when the terminate handler is called, immediately set it back to the
original one, so can't make a recursion if the crash-handling code fails
- Only save projects if the crash occured after Imhex finished startup
- do not update the project location when saving the crash backup file:
this will remove problems when `EventAbnormalTermination` is called
before `crashCallback()`
I also added a bit more documentation
