### Problem description
By default, the cursor's blinking cycle is independent from user
actions, which feels unconventional while editing pattern code. This
change ensures that the blinking cycle is reset, and the cursor is made
visible every time the editor receives a keyboard event like character
entry, or arrow navigation.
### Implementation description
I moved the hard-coded blink timing numbers to their dedicated static
constant fields since now they are referenced from multiple different
places.
I added the function `void ResetCursorBlinkTime()` to `TextEditor.cpp`
that will reset the blink cycle to `currentMillis() -
sCursorBlinkOnTime`, ensuring that the cursor is visible. This function
is called for every keyboard and mouse click event.
### Screenshots
Before:
https://github.com/WerWolv/ImHex/assets/45818400/668c6802-79a3-450b-80d3-d6abf2ce27be
After:
https://github.com/WerWolv/ImHex/assets/45818400/ee7f60e0-a75f-416d-b86d-8d12b5cdadf2
---------
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
This PR adds a shortcut link on the Search (Ctrl+F) popup to the more
advanced "Find" view that is normally accessible at the `View > Find`
menu.
### Implementation description
I added a simple `ImGuiExt::IconHyperlink` link to the `draw()` function
of the `PopupFind` class to display the hyperlink. Clicking the link
will open the Find view, bring it into focus and close the current
popup.
### Screenshots
Before:
After:
### Additional things
- Localization keys were added to all .json files, but only `en_US` is
populated for now.
### Problem description
Merging my previous PRs, #1660 and #1658 has resulted in a conflict
causing an application crash due to a missing `ImGui::BeginDisabled();`
in the `PopupSelect` class. Specifically, none of the code related to
offset validation made it into the final merge. This PR fixes the crash
by reintroducing the deleted lines.
### Additional things
The nightly release build seems to be unaffected by the crash, most
likely because ImGui's `DisabledStack` assertions are only enforced in
Debug mode. The offset validation was still missing before this fix.
### Problem description
In previous versions of ImHex, all tool windows were implemented as
static popups fixed in the upper left position of the hex view. This PR
refactors all tool popups to use floating windows that can be dragged
around by the user, or closed with a dedicated close button on the title
bar. These popup also support a stylable transparency when the user is
not hovering their mouse over the window.
### Implementation description
I rewrote the logic in `ViewHexEditor::drawPopup()` to use a custom
`ImGuiExt::BeginHoveringPopup` function for rendering the popup windows.
This new function is an almost exact replica of the built-in
`ImGui::BeginPopupModal`, except it does also displays the default
window title bar with a close button.
A second custom function, `ImGuiExt::PopupTitleBarButton` was also added
for rendering small icon-based buttons into the title bar of the parent
popup window. This new function was used to implement an optional
"Pinning" feature that individual popup implementations can specify. If
a window is pinned, it won't close automatically when its main action is
executed. For example, the "Select" button on the Select dialog will
close the popup by default, unless the window is pinned.
### Screenshots
Popup dialogs before:
Popup dialogs after:
https://github.com/WerWolv/ImHex/assets/45818400/99d1a628-8ac1-40ac-9146-9062091bb0db
### Additional things
- When the user stops hovering their mouse over a popup window, it
becomes semi-transparent, making it easier to see the content behind it
- This PR also introduces the `styles.imhex.popup-alpha` style, making
the transparency effect configurable, including the ability to disable
the effect completely by setting `popup-alpha` to `1.0`.
- Fixed a bug that caused some popup windows to ignore the Enter and the
KeypadEnter keys. With this PR, all tool windows will execute their main
action when the user presses either one of the two Enter keys, and will
also close automatically unless the window is pinned.
### Possible changes and improvements
- Should the transparency effect be disabled if a window is pinned?
- Should the transparency factor be modifiable on the Settings/Interface
page?
- A keyboard shortcut could be added for quickly pinning / unpinning the
current window.
- Can the pin icon stay on the left, or should it be moved next to the
close button, with a similar circular background?
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
### Problem description
This PR offers two improvements:
1) When selecting / jumping to an offset that falls within the current
viewport of the scroll view, the scroll offset will no longer force the
selected byte to the top of the view. Instead, the scroll offset will
only be changed if the selected byte is outside the current view.
2) In case a wrong offset is entered into the Select or Goto dialog
(e.g. and offset beyond EoF), the dialog's button will be disabled.
### Implementation description
For the first change, I modified the logic that recalculates the
`m_scrollPosition ` based on the current byte offset.
For the second change, I added validation logic to both popups to ensure
that the entered offsets are valid (using `provider->getActualSize()`).
In case of the Select popup, I wrapped the button into an
`ImGui::Begin/EndDisabled` to enforce the validation check.
### Problem description
When the close button is clicked, `ImGui::BeginPopupModal()` sets the
bool passed into the second parameter (p_open) to false. However, the
closing logic did not take this into account, making it difficult to
actually close modal popups.
For example, closing the "Export pattern File" modal took several clicks
on the "X" button, now it closes instantly.
### Implementation description
I added an additional check for the `open` variable being `false` in the
logic that checks the closing condition.
<!--
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
This PR aims to address #1645 that caused the built in file provider's
change monitor to trigger the notification popup dialog multiple times
in a row after multiple external file changes.
### Implementation description
I added an additional boolean field
`m_changeEventAcknowledgementPending` that tracks whether there are any
pending or unacknowledged change notification dialogs to prevent further
dialogs from being opened. The flag is only reset to its initial value
once the user has acknowledged the first `PopupQuestion` dialog.
Since the file is reloaded only after the user clicks 'Yes', it is
unnecessary to ensure that only the latest popup is acknowledged.
