On Windows SolveSpace 2.3 uses a plain dialog for `SolveSpace::Error` and
`SolveSpace::Message` with no icon and no system beep. After the GUI
abstraction was reworked this changed to the default system message boxes
(using MessageBoxIndirectW) that play the "Default Beep" sound and show
red "X" and blue "i" icons respectively.
The beep is annoying since the error and message dialogs are used often to
show required conditions for constraints, new groups and other behaviors.
This disables the beep and uses the SolveSpace icon.
Fixes: 719
On macOS actual scroll delta is used for the zoom amount.
On Windows WHEEL_DELTA is used to allow smooth scrolling if supported.
Shift+Scroll is added for 10x finer zooming.
Went through first the diff of the referenced commit,
then all instances of "Create(Open|Save)FileDialog";
added SuggestFilename() calls where a default exists
This has been previously removed in
6b5db58971Closes#538
Travis's move away from providing unlimited build time to OSS and its
inferior developer experience are the reason for this change.
The workflows are simple and straightforward, and the build scripts
are mostly 1:1 the same we used on Travis. This avoids vendor lock-in
as much as possible in case we need to move somewhere else in the future.
We introduce two workflows:
1. CD (cd.yml)
Runs on: Commits to master, GitHub releases.
Does: Run tests, build release assets, update GitHub edge release or
release to developer created GitHub release. Builds & uploads snaps to
the Snap Store.
2. Test (test.yml)
Runs on: Every commit except those on master and v* tagged ones.
I.e. PRs and other branches.
Does: Run tests only.
Creating a release is now an explicit operation. On the Travis workflow,
pushing a tag that begins with "v" will lead to the automatic creation of
an associated GitHub release.
On GHA, creating a GitHub release by hand will trigger the CD-workflow
to build & upload the release assets.
Other differences to Travis:
- Windows builds on Visual Studio 16 2019 instead of Visual Studio 15 2017.
- Snap builds run in docker containers, not directly on the build host.
- Snap arm64 builds on amd64 via QEMU user emulation.
This is slower than what Travis gave us and should be changed when/if
GHA offers ARM64 build runners.
- GHA retains build artifacts for 90 days by default.
Required secrets:
- MACOS_CERTIFICATE_PASSWORD
- MACOS_CERTIFICATE_P12
- MACOS_APPSTORE_APP_PASSWORD
- MACOS_APPSTORE_USERNAME
- MACOS_DEVELOPER_ID
- SNAPSTORE_LOGIN
Discussion: https://github.com/solvespace/solvespace/issues/807
PR: https://github.com/solvespace/solvespace/pull/824Fixes#807
The return value of these functions is not an error code and according to
the Win32 API documentation they can not affect `GetLastError`.
Calling sscheck on them normally does not fail since it does
SetLastError(0) before running the checked expression and only then
GetLastError(). However in issue 817 a user discovered that when running
"DisplayFusion" software GetLastError does return an error and SolveSpace
closes.
So while not a strict bug-fix this is a "correctness improvement" for
SolveSpace and works around a possible bug in DisplayFusion.
Similarly the return value of Reg*** functions is now compared to
ERROR_SUCCESS which is zero. Before the sschecks were strictly wrong but
did not cause problems for the same reason as above.
... is enabled.
"err" was first introduced in c2c26e95ad to indicate sketches that may cause
problems in the subsequent 3D groups. But is makes sense not to display the
error if the "check sketch for closed contour" option is turned off. The user
obviously does not want to be warned.
Based on a suggestion in https://github.com/solvespace/solvespace/issues/819
On scroll wheel events convert the mouse coordinates from screen to client
area so that scroll wheel zooming remains centered irrespective of the
window position.
Fixes https://github.com/solvespace/solvespace/issues/806
It was added in 3a3a2755b as a potential way to export colorful meshes
to Horizon EDA but ended up being supported only by SolveSpace. Since no
software can consume the exported q3do files the feature is superfluous.
See https://github.com/solvespace/solvespace/issues/795 for details.
With arm64-graviton2 now providing full VM virtualization, LXD containers
can be used to build snaps on all architectures.
This is beneficial for us as having snapcraft manage the whole build
environment is likely to yield better/more consistent results than
running the builds on the Travis images directly.
Our implicit deploy conditions were previously only met by untagged commits
on master. As the stage conditions filter everything except branch = master
and tagged commits, we can just use all_branches: true to also deploy tagged
builds.
Also clean up the snap deploy sections.
Reini Urban
ruevs
Jonathan Westhues
Ryan Pavlik
phkahler
app4soft
Koen Schmeets
наб
Maximilian Federle