- The deferred method scheduler is now automatically created
when required and when there is a QApplication
- QApplication and related have argv constructors
The reason was that for 0.25.1 "macro-editor-font-size" was allowed
to be an empty string (the default). Which meant: take default application
font size. In 0.25.2 this now was required to be a number and 0 was
the default for "auto" font size.
Two changes:
- The default is back to empty string ("0" is still allowed as default)
- The application was made safe against broken configuration files: an
error is printed to the log, but apart from that the application
will work (the configuration value is ignored however).
This is what's been done:
- remove the old double and single buffering /w mask approach
- modify the bitmap rendering so it's done in a offscreen
image before subsampling
(effect: rulers display smoothly in subsampling mode)
- refactoring the "device pixel ratio" topic:
Made the DPR a variable, viewport width is scaled up
to reflect the true image size, inserted #ifdef's for Qt4.
DISCLAIMER: I don't know whether this still works - I don't
have a Retina display :-(
Without this commit, bookmark menus got grayed out
on MacOS with Qt5 sometimes. Now, the implementation
of recent file menu, bookmark menu, macro menu and
the static main menu use the same framewkork which
includes a workaround for the disabled menu issue.
- ID's are used instead of pointers to identify menu items
vs. QAction's. This is a weak measure to enhance predictability.
- The file menu is built from abstract menu items instead with
native Qt objects. This way the bug fix applies both to
file menu items and the other menu entries
The main fix is:
- A menu sync is forced by emitting a focusWindowChanged event
from the application object. This forces the QCocoaMenuBar
implementation to update the system menu.
The issue is with "dllexport": previously, dllexport was present on
exposed templates tool (= visibility(default) for gcc/clang). This
ensured MacOS compatibility since then the typeinfo is corretly
shared and dynamic_cast/typeid works.
For Windows, the "dllexport" equivalent requires the template
instantiations to be declared "external" which is a coding nightmare.
The solution is to provide separate macros for real (non-specialized,
not explicitly instantiated) templates (.._PUBLIC_TEMPLATE) which
is defined as empty for Windows and "visiblity(default)" for gcc/clang.
1.) Startup issue:
This is solved by making sure templates with virtual functions
are made visible in the DSO. This way, dynamic_cast is possible
across DSO's.
Scary: clang/MacOS wants the forward declarations be declared visible as well.
2.) Menu issue:
The best solution is to have only one QMenuBar. The navigator
now gets a synthetic menu bar composed of QToolButtons.
The LLVM STL implementation does not recognize "typedef void iterator_traits"
as dummy declaration. It will fall back to an empty traits struct.
Using the default "forward_iterator_tag" for the iterator_traits solves
this compile issue.
The fix consisted of introducing "factory" type virtual
methods which ensure that a reference is held to the
returned object. This is important for implementing
factory methods in Python. Without this, the object
get destroyed before we have a chance to increment the
reference count.
Matthias Koefferlein
Thomas Ferreira de Lima
matthias