1
0
mirror of synced 2024-12-13 08:21:07 +01:00
Commit Graph

4270 Commits

Author SHA1 Message Date
WerWolv
cb475c471d build: Updated libwolv 2024-06-08 00:39:12 +02:00
WerWolv
bf82690c80 fix: Build and drawing of title bar buttons on macOS 2024-06-08 00:28:17 +02:00
WerWolv
72a3a1acab build: Updated libwolv 2024-06-07 23:48:57 +02:00
WerWolv
18e2b0eaa2 fix: Regex crashes with too long input strings 2024-06-07 23:12:18 +02:00
WerWolv
b80a6152b3 fix: Unifont being blurry again 2024-06-07 22:50:47 +02:00
WerWolv
ffe3dae7b2 build: Updated ImGui to v1.90.8 2024-06-07 22:12:50 +02:00
WerWolv
d7845ec690 fix: Build issues 2024-06-07 21:57:39 +02:00
WerWolv
8531a67519 fix: Don't unload background .NET scripts 2024-06-07 21:27:01 +02:00
WerWolv
af59b9d2ca fix: Infinite loop when doing forwards/backwards searches in some cases
Fixes #1734
2024-06-07 21:00:55 +02:00
Tsukasa OI
08bb69c048
fix: Wrong query path when saving layouts (#1735)
### Problem description

At least on Windows (I have tested), it fails to save a layout on the
non-portable version of ImHex (unless we have an administrator
privilege).

The log (after an attempt to save a layout as "sample") will look like:

| Component | Message |
| --------- | ------- |
| `libimhex` | `Failed to save layout 'sample'. No writable path found`
|

But the underlying problem is platform-agnostic. It can be also a
problem on other platforms in other ways.

### Implementation description

The layout manager incorrectly queried whether the empty path
(effectively the current working directory) is writable before saving
the layout (not each "layouts" directories it queried earlier).

This is the snippet of the root cause.

```cxx
std::fs::path layoutPath;
for (const auto &path : hex::fs::getDefaultPaths(fs::ImHexPath::Layouts)) {
    if (!hex::fs::isPathWritable(layoutPath))
        continue;

    layoutPath = path / fileName;
}
```

Look at the argument we are passing to `isPathWritable`. `layoutPath` is
a default (empty) `std::fs::path` object and will not be updated until
the directory describing itself is confirmed to be writable.

That caused a problem on non-portable version of Windows because:

1. The current working directory is usually the one of the executable
(`imhex-gui.exe`) and
2. That directory (`C:\Program Files\ImHex` by default) is usually not
writable unless ImHex is executed with an Administrator privilege.

The argument to `isPathWritable` should be `path` (containing one of the
`layouts` directories) and this PR fixes so that.

### Screenshots

### Additional things

This issue is hard to notice when developing because, to reproduce this
bug, the current working directory MUST NOT BE writable (usually
writable when we develop, even when we are working on the non-portable
Windows builds).
2024-06-07 20:33:43 +02:00
WerWolv
6fb32d20b3 fix: Don't try to compile process memory provider into Web build 2024-06-07 20:32:04 +02:00
WerWolv
ea09bfe8ea feat: Highlight patterns in pattern data view that are fully selected
Fixes #1741
2024-06-07 19:59:11 +02:00
WerWolv
c0dde570e4 feat: Highlight patterns in hex editor when hovering over pattern data row
Fixes #1742
2024-06-07 19:48:10 +02:00
WerWolv
6fd3fa77ed impr: Don't scroll hex editor view when jumping to a region that's on-screen already
Fixes #1743
2024-06-07 19:29:55 +02:00
WerWolv
ff20f81cfd impr: Added back selection size in hex to the footer 2024-06-07 19:21:38 +02:00
WerWolv
de8465a8f4 feat: Added limited support for the process memory provider to macOS 2024-06-07 19:17:14 +02:00
WerWolv
4540e1b561 impr: Select second to last provider when last one is selected and closed 2024-06-05 23:21:15 +02:00
WerWolv
789d469477 impr: Make providers close instantly 2024-06-05 23:02:38 +02:00
WerWolv
4797512207 fix: Variable naming style in splash window 2024-06-05 22:24:00 +02:00
WerWolv
348fe27a3c impr: Added small moon icon to the welcome screen of nightly builds 2024-06-05 22:23:43 +02:00
WerWolv
c217b1b100 build: Replace -WIP version suffix with .WIP 2024-06-05 20:59:48 +02:00
WerWolv
0e757e5fb1 build: Bumped version to 1.35.0-WIP 2024-06-03 23:06:28 +02:00
WerWolv
72d5707d33 build: Bumped version to 1.34.0 2024-06-03 22:22:33 +02:00
WerWolv
a491b85737 build: Added simple script to generate release notes 2024-06-03 22:14:08 +02:00
Alexander Wilms
d9d85cbfcc
impr: Added keywords to .desktop file (#1732)
<!--
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 adds a list of strings which may be used in addition to other
metadata to describe the application. This can be useful e.g. to
facilitate searching through entries.

Reference:
https://webcache.googleusercontent.com/search?q=cache:https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

(The original site is currently down due to a Gitlab upgrade)

These keywords are used by
[Flathub](https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#launchable),
[KDE
Discover](https://discuss.kde.org/t/does-kde-discover-parse-the-desktop-file-for-categories-and-keywords/7041)
and [Gnome
Software](https://blogs.gnome.org/hughsie/2016/01/07/the-importance-of-keywords-for-the-software-center/).

### Implementation description
<!-- Explain what you did to correct the problem -->
Add a `Keywords` entry to the .desktop file.

### Screenshots
<!-- If your change is visual, take a screenshot showing it. Ideally,
make before/after sceenshots -->

Here's how the tags are displayed for TeXstudio on its Flathub page: 

![image](https://github.com/WerWolv/ImHex/assets/3226457/35e00272-433e-46cd-9a9e-c42913aefe3f)


### Additional things
<!-- Anything else you would like to say -->
2024-06-03 19:44:05 +02:00
iTrooz
283fe46230
git: Replace Ubuntu 23.04 with 24.04 LTS (#1731) 2024-06-03 17:25:50 +02:00
iTrooz
2c00aa5def
fix: Do not use custom repo gcc 13 for Ubuntu because it doesn't run on vanilla Ubuntu (#1730) 2024-06-03 08:06:49 +00:00
iTrooz
984438e98d
feat: show Linux distribution information on startup (#1729) 2024-06-03 10:02:29 +02:00
WerWolv
cf34c4bd95 fix: The font atlas does not own the custom font data 2024-06-01 13:55:06 +02:00
WerWolv
bab1d2e27e fix: Loading custom fonts from paths with unicode characters not working
Fixes #1727
2024-06-01 13:52:41 +02:00
WerWolv
d1b6a21e86 fix: Missing localization 2024-05-31 17:06:18 +02:00
WerWolv
3049590b68 feat: Added full pattern path to hex editor hover tooltip 2024-05-31 17:02:46 +02:00
WerWolv
8a289d2e4f impr: Make hex editor faster to render 2024-05-31 17:02:22 +02:00
WerWolv
7a81fa7ac5 fix: Mutliple potential nullptr derefes with shortcuts 2024-05-31 17:02:08 +02:00
WerWolv
fbf59b6f0b build: Updated ImGui 2024-05-31 16:59:52 +02:00
WerWolv
0ab200f77f fix: Hex editor popups closing when opening sub-popups 2024-05-30 22:01:18 +02:00
WerWolv
a91e40d731 lang: Fixed typo 2024-05-30 21:49:40 +02:00
WerWolv
e553fbc86c patterns: Updated pattern language 2024-05-30 21:49:08 +02:00
WerWolv
b4a810c374 fix: Build error on some platforms due to unused variables 2024-05-30 21:49:01 +02:00
WerWolv
0e97914d94 build: Updated libwolv 2024-05-30 16:57:57 +02:00
WerWolv
a5c250c811 fix: Byte type annotations not being reset correctly 2024-05-30 16:57:28 +02:00
WerWolv
08c2f3fc15 impr: Make window less prone to flickering during resizes on Windows 2024-05-30 16:57:07 +02:00
WerWolv
63f66662ce fix: Workspaces not being deletable correctly in all cases 2024-05-30 16:56:39 +02:00
iTrooz
89eee104ab
chore: disable codecov PR comments (#1724) 2024-05-28 13:51:09 +02:00
iTrooz
92b1234ddb
build: Reduce debug info produced (#1720) 2024-05-27 16:33:15 +02:00
iTrooz
0b0bf90e0b
build: Compress debug info (#1719)
This PR compress the debug info in the ELF files built.

This has no impact on the packages (e.g. .deb files) because they themselves have compression, but once installed in the filesystem, they this compression will be beneficial

The compression is opportunistic, happens automatically when possible

For some reason, the web version doesn't work with this (most compiler tests after this seem to fail ?) so it is disabled there

More information: https://github.com/WerWolv/ImHex/issues/1714#issuecomment-2131373826
2024-05-26 20:48:14 +02:00
iTrooz
974c4ba040
git: remove unused name matrix parameter from Ubuntu builds (#1701) 2024-05-23 15:57:44 +02:00
iTrooz
4e2c1d20b4
git: change key used for web cache 2024-05-23 14:44:01 +02:00
iTrooz
e5b83d0ddf
chore: add comment about IMHEX_COMMON_FLAGS 2024-05-23 14:44:01 +02:00
David Mentler
bdaf1e4151
build: Xcode accomodating CMake setup (#1688)
### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.

### Implementation description

#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:

By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.

The result is different output directories when using Xcode, and no
changes when using any other generator.

#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.

In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```

This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.

#### Problem 3: Vanilla CMake + Xcode = Bad developer UX 
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.

Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.

The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.

### Screenshots
N/A

### Additional things

As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.

The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
2024-05-20 10:12:57 +00:00