<!--
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 -->
Fixed possible bug of `EventManager::unsubscribe`
`std::map` only allows unique key, but the same token can subscribe to
multiple events.
1a2a926b77/lib/libimhex/include/hex/api/event.hpp (L104-L107)
If the previous token has already subscribed to an event, then when
subscribing again, `getTokenStore().insert` will not do anything
(Because its type is `std::map`)
1a2a926b77/lib/libimhex/include/hex/api/event.hpp (L122-L134)
At this point in `unsubscribe`, the `iter` may not be able to find the
correct event and erase it
### Implementation description
<!-- Explain what you did to correct the problem -->
Change `tokenStore` to `std::multimap` instead of `std::map`, which
cannot unsubscribe multiple events correctly
### 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 -->
<!--
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
<!--
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
### Implementation description
Updated Traditional Chinese (Taiwan) translations for ImHex.
### 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 -->
### Problem description
The issue seems to only affect the web version of ImHex but it is not
clear why. The labels of the checkboxes that represent bits in the IEEE
745 floating point tool were lay out incorrectly.
### Implementation description
The new code ensures that the bit labels are centered and located in the
middle of the checkbox regardless of the font size and the dear imgui
sized checkboxes.
<!--
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 might fix building with capstone 4 as discussed in
https://discord.com/channels/789833418631675954/1155669027306340393/1155669027306340393
### Implementation description
<!-- Explain what you did to correct the problem -->
moves the max definition inside the if statement that checks for
capstone 5
<!--
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 will simplify the codebase in the pattern drawer. It returns early
on conditional statements and reduces the amount of nested code making
it easier to read and track while developing.
I noticed the bad score on code factor so I reorganized it to make it
more readable and maintainable. In order to break down the big function
into it much smaller parts I encapsulated all the variables that the
functions need to access in two classes, one for the imgui related
statics and the other for non-static variables.
When writing the smaller functions I was noticed that there was room to
simplify the existing algorithms by writing functions that could be
called by parts that previously shared no code. I tested the changes the
same way I tested the original and it seems to work the same way but
maybe a bit faster. Although it may be possible to further optimize the
present code code factor no longer flags the function at all.
As discussed (many times) on Discord, does the same as the new favorite
tag, but instead allows you to add multiple groups.
Initially, this would cause some insane issues with draw/reset
(apparantly) fighting eachother in the pattern drawer. After a lot of
trial and error, I decided to rewrite the flow that is responsible for
calling reset. Now evaluating patterns is the one to decide when the
reset happens, not the core "game"-loop.
To make sure that draw and reset can never happen at the same time, the
mutex originally used for the favorites has been repurposed. Due to the
restructuring, the mutex in the favorite-task is no longer needed, as
that will only ever kick-off after reset is called and if there are
actually patterns, which can never line up to be accessed on different
threads at the same time.
Last but not least, I noticed that hard crashes could result in your
config file getting overridden. I added a check to prevent that.
Last I issue I can see is that if you use an excessive amount of
favorites/groups, a crash can still happen, but it only happens when you
close the program (occasionally, but unpredictable). Before, this would
happen if you ran the evaluation a second time. I boiled the cause of
the crash down to these lines of code in evaluator.cpp >
patternDestroyed:
```cpp
if (pattern->isPatternLocal()) {
if (auto it = this->m_patternLocalStorage.find(pattern->getHeapAddress()); it != this->m_patternLocalStorage.end()) {
auto &[key, data] = *it;
data.referenceCount--;
if (data.referenceCount == 0)
this->m_patternLocalStorage.erase(it);
} else if (!this->m_evaluated) {
err::E0001.throwError(fmt::format("Double free of variable named '{}'.", pattern->getVariableName()));
}
}
```
Specifically, trying to access the `*it` is the reason for the crash
(this was also the cause of the crashes before my fixes, but then during
evaluation).
I'm suspecting the root cause is somewhere in the `.clone` methods of
the patterns. I'd say that for now a crash when closing the program is
more acceptable than during evaluation (which can even happen if you use
favorites).
