Web: Emscripten port updated to current tools. Add saving of options in local storage.
U Web: Emscripten port updated to current tools. Add saving of options in local storage.
The default icon for XDG mimetypes is the name of the mime with '/'
replaced with '-', unless the mimetype has an 'icon' attribute (and
solvespace-mime.xml does not have it). So the right icon name for
application/x-solvespace is 'application-x-solvespace', not
'application.x-solvespace'. Hence, properly rename the mimetype icons
in non-flatpak and non-snap installations.
They were added with commit a98cdeeb16
and they were only useful for the old Debian menu system, which was
deprecated almost 6 years ago [1]. As the old Debian menu file is no
more provided in the Debian packaging, the XPM versions of the
application icon can be safely removed, as there are already icons in
the XDG hicolor icon theme.
[1] https://lists.debian.org/debian-devel-announce/2015/09/msg00000.html
Also, mark not just curves, but also points and normals derived from
construction requests as construction.
Also, don't always mark arc center point as construction just to
exclude it from chord tolerance bounding box calculation; instead,
special-case it there.
Before this commit, the default font chosen for TTF text is Arial
(chosen by the basename of arial.ttf), which isn't present on most
Linux systems, and cannot be redistributed. After this commit, it is
replaced with Bitstream Vera Sans, which can be. Existing files
are not affected.
The font name in the TTF file was artificially modified to add
the (built-in) suffix, which will need to be done if more built-in
fonts are added.
This commit removes a large amount of code partially duplicated
between the text and the graphics windows, and opens the path to
having more than one model window on screen at any given time,
as well as simplifies platform work.
This commit also adds complete support for High-DPI device pixel
ratio. It adds support for font scale factor (a fractional factor
on top of integral device pixel ratio) on the platform side, but not
on the application side.
This commit also adds error checking to all Windows API calls
(within the abstracted code) and fixes a significant number of
misuses and non-future-proof uses of Windows API.
This commit also makes uses of Windows API idiomatic, e.g. using
the built-in vertical scroll bar, native tooltips, control
subclassing instead of hooks in the global dispatch loop, and so on.
It reinstates tooltip support and removes menu-related hacks.
This commit fixes four issues:
* Instead of WRITE,APPEND, resource.rc was generated using
WRITE,WRITE, which erased #include <windows.h> and prevented
any symbolic definitions (like RT_MANIFEST) from working.
This silently included them using a string type instead,
which did nothing.
* WINVER is bumped to Win7, since that's what we target now.
* Index of RT_MANIFEST is changed to 2, since that's what
it has to be when ISOLATION_AWARE_ENABLED is defined.
* Platform is not restricted to X86 in manifest, since there
is no point in doing so.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
There are two main reasons to desire an OpenGL 2 renderer:
1. Compatibility. The compatibility profile, ironically, does not
offer a lot of compatibility, and our OpenGL 1 renderer will not
run on Android, iOS, or WebGL.
2. Performance. The immediate mode does not scale, and in fact
becomes very slow with only a moderate amount of lines on screen,
and only a somewhat large amount of triangles.
This commit implements a basic OpenGL 2 renderer that uses only
features from the (OpenGL 3.2) core profile. It is not yet faster
than the OpenGL 1 renderer, primarily because it uses a lot of small
draw calls.
This commit uses OpenGL 2 on Linux and Mac OS X directly (i.e. links
to the GL symbols from version 2+); on Windows this is impossible
with the default drivers, so for now OpenGL 1 is still used there.
The states are:
* Draw all lines (on top of shaded mesh).
* Draw occluded (by shaded mesh) lines as stippled.
* Do not draw occluded (by shaded mesh) lines.
As usual, the export output follows the screen output.
This commit integrates the vector font in the resource system, so
that cross-compilation would be easier and a custom font could be
used without recompilation.
The font handling code was carefully written to lazily load glyphs;
as possible; in practice this means that startup is less than 15ms
slower after this commit, most of it spent in inflate().
This also reduces executable size and makes compilation of
glhelper.cpp much faster.
This commit integrates the bitmap font in the resource system, so
that cross-compilation would be easier.
The font handling code was carefully written to do glyph parsing
lazily; in practice this means that after this commit, startup
is less than 25ms slower, most of it spent in inflate().
This should also result in faster rendering, since there is no
rampant plane switching anymore; instead, all characters that are
actually used are stashed into same one texture.
This commit integrates icons in the resource system so that they
can be loaded (or reloaded, without restarting) in @2x mode, which
will be added in a future commit. png2c is no longer necessary.
png2c used to perform the following transformation:
if(r + g + b < 11) r = g = b = 11;
This is now achieved by switching the icons to RGBA mode and adding
alpha channel with the following imagemagick invocation, which is
equivalent to the transformation above:
for i in *.png; do
convert -fuzz 4% -channel rgba -matte \
-fill "rgba(255,255,255,0)" -opaque black \
$i $i
done
The Debian package solvespace now includes /usr/share/solvespace;
this should be split out into solvespace-data later.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
77maxikov
whitequark
strzinek
verylowfreq
phkahler
Pino Toscano
Ryan Pavlik
Koen Schmeets
ZHOU You
Maximilian Federle
Pierre Delore
Kevin Zheng
EvilSpirit
AppSoft4
Elvira Khabirova