Testing various fonts and sizes I realized there were still problems
with the layout of the bit labels. Also I reorganized the code so that
lambdas are defined just before they are used. Comments needed
punctuation too.
Part of the problem was that I had been assuming all along that the
check boxes were ImGui's originals which are always square. In actuality
the width is determined by the width of the character for '0'. Also
ImGui table was adding spacing to separate cells which made the boxes
not start at same place as column. Also for some reason using indent of
zero didn't work as expected but using 0.1 pixels worked. With those
problems fixed it is fairly easy to make sure the labels are centered at
the box except when the first mantissa checkbox gets a label which is
wider that the box width. Before and after show results for different
fonts.
Before:
After:
### Implementation description
I synchronized the json key order with `en_US.json` in each lang file.
### Additional things
Here are simple python script that make this change
```python
import json
from collections import OrderedDict
original = "./en_US.json"
modified = [
"./de_DE.json",
"./es_ES.json",
"./it_IT.json",
"./ja_JP.json",
"./ko_KR.json",
"./pt_BR.json",
"./zh_CN.json",
"./zh_TW.json",
]
for modify in modified:
dict_2 = {}
with open(original, 'r', encoding='utf-8') as f1, open(modify, 'r', encoding='utf-8') as f2:
dict_1 = json.load(f1)
dict_2 = json.load(f2)
dict_1_translations = dict_1["translations"]
dict_2_translations = dict_2["translations"]
ordered_dict_2 = OrderedDict((k, dict_2_translations[k]) for k in dict_1_translations.keys())
dict_2["translations"] = ordered_dict_2
with open(modify, 'w', encoding='utf-8') as f2:
json.dump(dict_2, f2, ensure_ascii=False, indent=4)
```
This PR integrates my libmagic patch into the Dockerfile rather than my
vcpkg fork (so we can use the official vcpkg repository in the future)
That said, we still use my vcpkg fork for now because official vcpkg
fails to compile freetype
<!--
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
