This reverts commit f1e47e6554.
Since unfortunately it breaks the addition of the git commit hash
to the version string when building from the VisualStudio IDE.
I presume this happens because `git` is not of the "path" of the
build environment. The version string ends up "3.0~" only.
The old approach of reading .git/HEAD does not work when using git
worktrees, where the folder layout looks roughly like:
solvespace.git/ - bare clone (.git dir)
solvespace.git/work - example worktree containing master
solvespage.git/worktrees/work/ - .git dir of worktree
solvespage.git/worktrees/work/HEAD - actual HEAD ref for master
First attempt was to just get GIT_ROOT from `git rev-parse --git-dir` but
that wasn't enough, since:
1. GIT_ROOT points to solvespage.git/worktrees/work/
2. GIT_ROOT/HEAD points to refs/heads/master
3. GIT_ROOT/refs/heads/master does not exist but the old implementation
would want to use this to get the sha
so we need two invocations of git rev-parse
1. `git rev-parse --git-dir` to get GIT_DIR
needed for setting GIT_DEPENDS
2. `git rev-parse HEAD` to get the sha of the worktree's HEAD
This makes appropriate vectors/normals explorable/selectable and closes#165.
This is a clean implementation that follows the style of the UI code for
the text window. Previous unmerged attempts from the above issue are:
eb3db32059782a5bbbe6a77cedbfd841e55b3d79
This makes all points explorable/selectable and fixes#165 partially.
This is a clean implementation that follows the style of the UI code for
the text window. Previous unmerged attempts from the above issue are:
eb3db32059782a5bbbe6a77cedbfd841e55b3d79
When the text window/property browser is closed while and edit box
is active its window remained open. This is incorrect and probably
causes a hang on Linux described in #1168. So hide the edit control
when closing.
* CMake: use PROJECT_VERSION instead of solvespace_*_VERSION
In 006539b, solvespace_MAJOR_VERSION etc. were removed.
However, these variables were still referenced in some places.
Solution: Use PROJECT_VERSION instead.
* CMake: re-add link directories for solvespace target
006539b removed the call to link_directories for gtkmm, jsonc & fontconfig.
This leads to linking errors if those libraries are in "non-standard"
paths.
Fix this by introducing a target specific target_link_directories call.
Fixes#1173
* snap: port to core20 & adapt to CMake changes
Moving to core20 was long overdue anyway, and
the recent CMake changes necessitated some fixes.
Also switch to LZO compression for (way) better cold start
performance.
1. We are making FoldConstants first, so we are copying less amount of data in DeepCopyWithParamsAsPointers.
2. Since we already perform DeepCopyWithParamsAsPointers, PartialWrt already produces params as pointers
When SolveSpace tries to display an Unicode code point (e.g. U+EA00 )
that does not exist in the embedded vector font (unifont.hex.gz) it hangs
in an endless loop in
`const BitmapFont::Glyph &BitmapFont::GetGlyph(char32_t codepoint)`.
The reason is that the binary search through the text file unifont-8.0.01.hex
that does the "lazy loading" of glyphs does not end.
Here is a short excerpt from the file:
```
D7FE:00007FFE63866DF66DEE6DDE63DE7FFE7FFE61866FBE638E6FBE6F867FFE0000
D7FF:00007FFE63866DF66DEE6DDE63DE7FFE7FFE61866FBE638E6FBE6FBE7FFE0000
F900:0080108810881FF8100800007FFE00000FF008100FF00810042002447FFE0000
F901:00047FFE008010841FFE10841FFC10841FFC10840880050003000CC0703E0000
```
When searching for `0xEA00` after some iterations of the while loop
2450010bbf/src/resource.cpp (L567)
both `first` and `last` end up pointing to F900. After that on each
consecutive iteration of the loop `last` ends up pointing to the LF (0x0A)
just before F900
2450010bbf/src/resource.cpp (L585)
and then `mid` ends up back on F900 here
2450010bbf/src/resource.cpp (L570)
and this will repeat enlessly.
The solution is to do
```
first++;
```
here
2450010bbf/src/resource.cpp (L591),
which will make `first==last` and change whe while loop contition to `while(first < last) {` thiw will
allow the while loop to exit.
Tested with
- 0xEA00 - non existent, not found in 16 iterations.
- 0xF900 - exists but takes exactly 16 iterations of the binary search to finish
- 0x0000 - found in 16 iterations
- 0xFFFD - the replacement Unicode code point for non-existing glyphs. Also the end of the font.
- 0xFFFFF - a codepoint beyond the end, not found and does not cause an exception
The lazy parsing of the vector front was introduced here.
645c2d90acFixes#1150