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.
Before this commit, if a pt-line-distance constraint is placed so
that the dimension line doesn't touch the line, no extension is
drawn. After this commit, an extension line will be drawn towards
the nearest end of the line.
This is an artificial restriction that serves no useful purpose.
Just switch to the previous group if asked to delete the current
one.
The ClearSuper() calls are reshuffled, since TW.ClearSuper() calls
TW.Show() and so has to be called while the sketch is still valid,
whereas GW.ClearSuper() also recreates the default group and thus
it should be called after the first RemoveById+GenerateAll pair,
or it'll recreate the default group before the entities on it have
a chance to be pruned.
Switching active group by itself is not an editing but a viewing
action; the active group is not recorded in the savefile. However,
the entity visibility status is, and this is annoying when source
control is used, because e.g. looking up dimensions in one of
the inner groups whose display was turned off ends up changing
the savefile.
When the display has to be turned on manually, this modification
of the file becomes explicit, so there's no longer any question
of what action modified the file.
This can also be convenient when inserting a group in the middle
of the stack, which will be implemented in the future.
Most of these were just converting char* into std::string back and
forth; some more used ReadUTF8, which was converted to use nicer
STL-style iterators over UTF-8 text.
The remaining ones are:
* arguments to Expr::From, which we'll change when refactoring
the expression lexer;
* arguments to varargs functions, which we'll change when adding
localization (that requires custom printf-style functions to
allow for changing argument order);
* arguments where only string literals are ever passed, which
are OK;
* in platform-specific code, which is OK.
CMake can properly quote inputs to custom commands itself; this is
governed by the VERBATIM flag. If we pass this flag, no quoting
needs to be done except for compiler/linker flags and diagnostic
messages, as CMake doesn't treat whitespace expanded from variables
the same way it treats whitespace that separates arguments.
This will weed out compilers that are too old to build our code
(among others, recent gtkmm and glibmm have a hard dependency on
C++11, not even C++0x) and also properly communicate our wish to GCC
(Clang defaults to C++11 these days).
Scoped "Zoom to Fit" is convenient for working on large models.
I (whitequark) have considered a separate shortcut, but its
usefulness is unclear and in any case it can be easily added
if desired.
In my (whitequark's) experience this warning tends to expose
copy-paste errors with a high SNR, so making a few fragments
slightly less symmetric is worth it.
Also mollify -Wlogical-op-parentheses while we're at it.
After commit 2f734d9, inactive groups are no longer regenerated
for trivial changes, e.g. changing parameters, so it's possible to
switch to an earlier group and work on it without incurring
the computational (slowdown) and cognitive (annoyance by red
background) overhead of later groups failing to solve.
However, if a group--any group anywhere--was not solved OK,
the interface reacted accordingly, which diminished usefulness of
the change, especially given that, if we have groups A and B with
B depending on A, if B is broken by a change in A and we activate A
and fix it, B will not be regenerated.
After this commit, only active groups are considered when deciding
if generating the entire sketch would fail.
This font is less complete than our bitmap font, Unifont: Unifont
has essentially complete Unicode coverage and LibreCAD's font only
has Latin, Cyrillic and Japanese, but it can be extended rather
easily, so this should be fine for now.
These embedded fonts fatten glhelper.o quite a bit:
bitmapfont.table.h is about 8M in gzip-compressed bitmaps and
vectorfont.table.h is about 2M in raw vector data.
In spite of that it takes just around five seconds to build
glhelper.c on my laptop, so it should be fine.
The final executable grows from about 2M to about 8M, but this
is a small price to pay for fairly extensive i18n support.
The new font has somewhat different metrics, so the rendering
code has been fudged to make it look good.
Benefits:
* Much simpler code.
* Handles the entire TTF spec, not just a small subset that
only really worked well on Windows fonts.
* Handles all character sets as well as accented characters.
* Much faster parsing, since Freetype lazily loads and
caches glyphs.
* Support for basically every kind of font that was invented,
not just TTF.
Note that OpenType features, e.g. ligatures, are not yet supported.
This means that Arabic and Devanagari scripts, among others, will
not be rendered in their proper form.
RTL scripts are not supported either, neither in TTF nor in
the text window. Adding RTL support is comparatively easy, but
given that Arabic would not be legibly rendered anyway, this is not
done so far.
EvilSpirit
whitequark
Adam Jaremko
Peter Barfuss