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:
### 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.
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).
From #1265, Looks like Error Popup doesn't handle properly in some
circumstances.
---------
Co-authored-by: iTrooz <hey@itrooz.fr>
Co-authored-by: WerWolv <werwolv98@gmail.com>
### Problem description
Ref #1210
### Implementation description
Call
[`SetFileTime()`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfiletime)
everytime `FileProvider::save()` is called.
### Additional things
I moved the call to `File::close()` from `FileProvider::open()` to
`FileProvider::close()` because `SetFileTime()` requires a file handler
as input, so I need `File::m_file` to be valid.
<!--
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
- Fixed disk provider not working for linux
### Implementation description
- Used ioctl instead of fstat
- Fixed buffer issues
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
### Problem description
Currently, the providers use the method `isSavable()` to determine both
if they can use "Save" or "Save as".
This behaviour is problematic because some providers may need to be
saveable but not saveable as: for example the view provider. The
original provider may not allow to be saved.
### Implementation description
I separate these two behaviour by creating another function:
`isDumpable()`, that return true by default but can be overridden by the
provider to return false, if the provider should not be dumped in any
way.
### Additional things
While I was at it, I also marked "export" operations as needing the
"dumpable" flag. That way, we can't accidentally export the whole
address space of a process as base64.
I also added documentation for these some functions in Provider
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
In order to do this I add to make some other additions :
- Add a warning popup (TODO, maybe add some icons to differentiate
error/warning popups in a future PR ?)
- create showError() and showWarning() functions, as helpers to show a
message both to the logs and as a popup
This PR updates imgui and its dependencies from the last time, ~1 year
ago
(deabacbd50)
Commits will be refactored before merging
Things you might ask :
- why did you remove `ImGui_ImplGlfw_SetBorderlessWindowMode()` ?
-> Where is it used ? The only usage of it I see is commented
(cb9a3b1f55/lib/external/imgui/source/imgui_impl_glfw.cpp (L757))
- why did you remove the implot anti aliasing flag ?
-> They.. seem to have removed it altogether ?
https://github.com/epezent/implot/issues/479
This PR does two things :
- save opened projects as recent entries
- refactor stuff about recent entries in a separate file. The reason is
that I felt like welcome_screen.cpp was really big ( 685 lines before
this, 500 now). What do you think ?
---------
Co-authored-by: Nik <werwolv98@gmail.com>
Really small issue, in Help->About->Imhex directories, there would be an
extra entry at the end because you seemed to loop over the
fs::ImHexPath::END entry
- Add a new file 'crash.json' to store metadata about the crash, like
the log file or project opened
- show the log file of the session that caused the crash to the user
- Correctly restore the project path
I just realized one feature request existed about this tool and have
added a comment to it referring this pr. Errors and additions are
described in the fork commit already. I'm not sure if I should repeat
them here again. I have tested the changes thoroughly, but it is always
possible some fringe case was not tested and is incorrect. The tests
were done using the many similar online calculators for IEEE 754
floating point formats.
IEEE 745 floating point tool redesign modeled after 'float toy' web app
(http://evanw.github.io/float-toy/)
Streamlined output using colors and compact layout which can be further
simplified.
Chosen display mode (detailed or simplified) is automatically saved and
set on new sessions.
Edit the binary bits, the integer hexadecimal or the floating point
decimal values and the entire app will update with the change.
Supports the main IEEE745 standard formats (half, single and double
precision) together with custom formats of size <= 64 bits.
Each format choice uses and displays the number of significant decimal
digits defined by the mantissa size.
Added labels to identify the location of each bit box inside the binary
representation.
Satisfies round trip / idempotent (reproducing) conversion property
Added theme colors, radio buttons for display mode and a clear button
that resets the tool.
Removed previously and incorrectly added locale translation to various
labels and languages
Attempted to adhere to code style formatting using existing code as
example.
An effort was made to use preferred variable types and functions from
std namespace when appropriate.
Attempted to document code using comments.
Not implemented / left to complete at an later time
Arbitrary width and precision formats.
Extended precision formats.
Shortest string property.
hexadecimal floating point display and conversions.
This is aimed at use by linux distros, where package updates come from a
central location, and users shouldn't need to worry about updating ImHex
on their own. This disables parts of the ImHex UI that would not be
useful in that case.
Tested and confirmed that this works in both states of the of the
`-DIMHEX_DISABLE_UPDATE_CHECK` switch.
This PR adds some documentation. It's actually pretty random, I followed
the function calls I was curious about and commented whenever I wasn't
sure/I thought it needed clarification
You might want to make sure to squash them, because the commits are kind
of a mess, I didn't went through the effort of interactive rebase
This PR does two correlated things:
- Show a generic error message (Failed to open provider) rather than a
file-specific message (Failed to open file) when a provider fails to
open
- Set the error to something more specific when opening a file fails
