This hint is not recommended for direct use by applications, and for
a good reason: it's very annoying. Moreover, what we want is not
"keep above" but rather "keep on the same layer as graphics window",
which is already achieved by setting window type to "utility"
on GNOME and Unity WMs, and by setting the transient window hint
for the text window on KDE WM.
This screws up window managers like fvwm, which don't respect
the ICCCM "Keep Above" flag. I don't remember why it's there and
it doesn't appear that removing it has any ill effect.
This is good practice and helps to catch bugs. Several changes
were made to accomodate the newly enabled warnings:
* -Wunused-function:
* in exposed/, static functions that were supposed to be inlined
were explicitly marked as inline;
* some actually unused functions were removed;
* -Wsign-compare: explicit conversions were added, and in
the future we should find a nicer way than aux* fields;
* -Wmissing-field-initializers: added initializers;
* -Wreorder: reordered properly;
* -Wunused-but-set-variable: remove variable.
-Wunused-parameter was turned off as enabling it would result in
massive amount of churn in UI code. Despite that, we should enable
it at some point as it has a fairly high SNR otherwise.
This is done because a meaningful union extrusion is almost never
a meaningful difference extrusion, and saves a bunch of common
manual work.
To avoid creating invalid sketches this isn't done when there are any
constraints.
Specifically:
* touchscreen devices are now supported;
* rotation is now more like what SolveSpace itself does.
The code is split in two parts because MSVC can't handle string
literals longer than 16Ki.
Before this commit, when exporting a vector file without the shaded
model shown, or similarly when using formats that we do not export
the mesh to, we still generate (and then discard) the mesh in paint
order. This is a waste of time.
The immediate reason for refactoring this was that the GTK port broke
after 52af7256 since config.h is not included anymore, but it was
a fragile piece of code I will shed no tears for.
While we're at it, get rid of the mutable std::string &file to be
consistent with our conventions.
config.h now includes the git hash and so, as long as it's included
in solvespace.h, any change of git HEAD will trigger a complete
recompilation, which makes bisecting especially annoying.
While we're at it, remove HAVE_STDINT_H from it, since we require
C++11 and all MSVC versions that include C++11 also include stdint.h.
Specifically:
* Group Info
* Style Info
* Assign to Style → Newly Created Custom Style...
These context actions are meaningless without viewing or manipulating
text window.
Before this commit, the initial state allCoplanar=false took
precedence over allNonZeroLen=false, since detecting a zero-length
edge short-circuits AssembleLoops.
Grid fitting is performed only on glyph boundaries, since glyphs
include curves converted to pwl, which would be mangled by per-point
grid fitting.
Grid fitting is only performed when the plane in which text is
laid out is parallel to the viewing plane.
Grid fitting is only performed when rendering for display; there
are no devices with dpi low enough for grid fitting to become
profitable, and in any case we cannot predict what the dpi would
be anyway.
First, a larger origin offset is applied in ssglWriteText. This moves
the text so that it doesn't overlap the workplane boundary.
Second, a different offset is applied in ssglWriteTextRefCenter.
After this, the middle stroke of "E" is vertically aligned with
the reference point, and the overall label is horizontally aligned
with the reference point more precisely.
Before this commit, the graphics window edit control always had
a width of 30 average character widths.
After this commit, the edit control has a width of 5 average
character widths (for numeric constraints) or 30 average character
widths (for comment constraints), or just enough to display
the entire value being edited, whichever is greater.
This makes the edit control overlap the sketch less in case of
editing numeric constraints (since in most cases, the numbers being
edited are short), and removes annoying scrolling in case of editing
long comments.
Before this commit, the position of the edit box was adjusted
by trial and error, as far as I can tell. This commit changes
the positioning machinery for edit controls as follows:
The coordinates passed to ShowTextEditControl/ShowGraphicsEditControl
now denote: X the left bound, and Y the baseline.
The font height passed to ShowGraphicsEditControl denotes
the absolute font height in pixels, i.e. ascent plus descent.
Platform-dependent code uses these coordinates, the font metrics
for the font appropriate for the platform, and the knowledge of
the decorations drawn around the text by the native edit control
to position the edit control in a way that overlays the text inside
the edit control with the rendered text.
On OS X, GNU Unifont (of height 16) has metrics identical to
Monaco (of height 15) and so as an exception, the edit control
is nudged slightly for a pixel-perfect fit.
Also, since the built-in vector font is proportional, this commit
also switches the edit control font to proportional when editing
constraints.
Before this commit, solids in the viewport were rendered with
"emphasized edges", with the intention to highlight selectable faces.
However, selectable faces are already surrounded by entities, and
so rendering emphasized edges adds little value.
After this commit, solids in the viewport are always rendered with
"sharp edges", like they are exported.
A new button is added, "Show/hide outline of solid model".
When the outline is hidden, it is rendered using the "solid edge"
style. When the outline is shown, it is rendered using the "outline"
style.
In SolveSpace's true WYSIWYG tradition, the 2d view export follows
the rendered view exactly.
Moreover, shell edges are not rendered anymore, since there is not
much need in them anymore and not drawing them lessens the overlap
between various kinds of lines, which already includes entities,
solid edges and outlines.
Before this change, the two buttons "Show/hide shaded model" (S) and
"Show/hide hidden lines" (H) resulted in drawing the following
elements in the following styles:
Button | Non-occluded | Non-occluded | Occluded | Occluded
state | solid edges | entities | solid edges | entities
--------+--------------+--------------+-------------+--------------
!S !H | | | solid-edge | entity style
--------+ | +-------------+--------------
S !H | | | invisible
--------+ solid-edge | entity style +-------------+--------------
!S H | | | |
--------+ | | solid-edge | entity style
S H | | | |
--------+--------------+--------------+-------------+--------------
After this change, they are drawn as follows:
Button | Non-occluded | Non-occluded | Occluded | Occluded
state | solid edges | entities | solid edges | entities
--------+--------------+--------------+-------------+--------------
!S !H | | | solid-edge | entity style
--------+ | +-------------+--------------
S !H | | | invisible
--------+ solid-edge | entity style +-------------+--------------
!S H | | | |
--------+ | | hidden-edge | stippled¹
S H | | | |
--------+--------------+--------------+-------------+--------------
¹ entity style, but the stipple parameters taken from hidden-edge
In SolveSpace's true WYSIWYG tradition, the 2d view export follows
the rendered view exactly.
Also, it is now possible to edit the stipple parameters of built-in
styles, so that by changing the hidden-edge style to non-stippled
it is possible to regain the old behavior.
Before this commit, "emphasized edges" were displayed as well as
exported. An "emphasized edge" is an edge between triangles that
come from different faces. They are helpful in the rendered
display because they hint at the locations of faces, but not
in the 2d export since they just clutter the drawing.
After this commit, "emphasized edges" are displayed but "sharp
edges" are exported. A "sharp edge" is an edge between triangles
where the two matching vertexes have different normals, indicating
a discontiguity in the surface. "Sharp edges" are also displayed
while post-viewing the exported geometry.
According to the C++ standard, "this" is never NULL, so checks
of the form "if(!this)" can be legally optimized out. This
breaks SolveSpace on GCC 6, and probably on other compilers and
configurations.
Fix iconutil build errors: “Iconset contains no image resources.”,
followed by “Failed to generate ICNS.”
The error is produced by iconutil because the AppIcon.iconset contains
only symbolic links to the icon resources which aren’t followed.
Replace the symbolic links with duplicates of the original resources,
as well as conform to the “High Resolution Guidelines for OS X” by
adding additional sizes and dpi.
This change is quite subtle. The goal is to improve responsiveness
of highlighting even further. To understand this change you need
to keep in mind that Windows and Gtk have dramatically different
behavior for paint (WM_PAINT in Windows, expose in Gtk) and
mouse move events.
In Windows, WM_PAINT and WM_MOUSEMOVE, unless sent explicitly,
are synthesized: WM_MOUSEMOVE is delivered when there are no other
messages and the current cursor position doesn't match the remembered
one, and WM_PAINT is delivered when there are no other messages,
even WM_MOUSEMOVE. This is pretty clever because it doesn't swamp
programs that are slow to process either of those events with even
more of them, ensuring they remain responsive.
In Gtk, expose events are delivered at the end of the frame whenever
there is an invalid view, and every single mouse move that happened
will result in a separate event.
If mouse move events are handled quickly, then the behavior is
identical in either case:
* process mouse move event
* perform hit testing
* invalidate view
* no more events to process!
* there are invalid views
* repaint
If, however, mouse move events are handled slower, then the behavior
diverges. With Gtk:
* process mouse move event
* perform hit testing (slow)
* while this happens, ten more mouse move events are added
* invalidate view
* end of frame!
* there are invalid views
* repaint
* process mouse move event...
As a result, the Gtk-hosted UI hopelessly lags behind user input.
This is very irritating.
With Windows:
* process mouse move event
* perform hit testing (slow)
* while this happens, mouse was moved
* invalidate view
* process mouse move event...
As a result, the Windows-hosted UI never repaints while the mouse
is moved. This is also very irritating.
Commit HEAD^ has fixed the problems with Gtk-based UI by making
hit testing so fast that mouse move events never quite overflow
the queue. There's still a barely noticeable lag but it's better.
However, the problems with Windows remained because while the queue
doesn't *overflow* with the faster hit testing code, it doesn't go
*empty* either! Thus we still don't repaint.
This commit builds on top of HEAD^ and makes it so that we don't
actually hit test anything if we haven't painted the result of
the previous hit test already. This fixes the problem on Windows
but also helps Gtk a little bit.
Curiously, the Cocoa-based UI never suffered from any of these
problems. To my understanding (it's somewhat underdocumented), it
processes mouse moves like Windows, but paints like Gtk.
This results in massive performance improvements for hit testing.
Files with very large amounts of entities (e.g. [1]) inflict
a delay of several seconds between moving the pointer and
highlighting an entity in commit HEAD^^^, whereas in this commit
the delay is barely perceptible.
[1]: http://solvespace.com/forum.pl?action=viewthread&parent=872
Before this commit, trying to export image on *nix platforms yielded
a black rectangle, since since there is nowhere to render to
when we're not in a GUI toolkit draw callback.
On Windows, nothing changes: we do a repaint without the toolbar,
glReadPixels, export. On *nix, we create another offscreen rendering
context, render into it, then destroy it. As a bonus this avoids
some minor flickering that would happen if we reused the regular
rendering path.
We had to fork libdxfrw since the upstream doesn't have a git
repository, a CMake buildsystem, and is quite buggy.
libdxfrw is also used in LibreCAD, but they just vendored
their version.
whitequark
EvilSpirit
Adam Jaremko