With both Qt4 and Qt5, when using a click-to-focus policy, the first
attempt to paste a selection by middle mouse in an external application
which has no focus may fail. It is not clear why this succeeds for some
applications and fails for others, but refreshing the timestamp of the
selection request cures the issue. The cmake part is by Kornel.
See also this thread:
http://thread.gmane.org/gmane.editors.lyx.devel/162491
dealing properly with the paragraph separator tag.
We really need to use that tag as a kind of general marker for which
tags we're responsible for in a given paragraph and which tags we are
not. So the changes to InsetText.cpp use the tag as that kind of marker.
Note that, as of this commit, the User Guide again exports without any
kind of error. I haven't yet checked the other manuals.
This fixes bug #8022.
Although this a problem that only manifests itself on windows the change is general
and it works anywhere.
The major change is to change the file redirection > to -o the specifies the output file.
At the same time it makes the call to lyx2lyx less cryptic, e.g. to revert to the 1.3
format we have:
\converter lyx lyx13x "python -tt $$s/lyx2lyx/lyx2lyx -t 221 $$i > $$o" ""
now instead of
python -tt $$s/lyx2lyx/lyx2lyx -t 221 $$i > $$o
we use a call where the version to revert is explicit
python -tt $$s/lyx2lyx/lyx2lyx -V 1.3 -o $$o $$i
or we could write a longer, but more understandable form:
python -tt $$s/lyx2lyx/lyx2lyx --final_version 1.3 --output $$o $$i
FWIW I shuffled the order of the arguments just for the sake of readability,
to let $$i be the last argument.
If the Qt directory is specified by --with-qt-dir, the full path
of the tools is retained. Otherwise, if qtchooser is detected,
the generic names are attempted with proper arguments to select
the desired Qt version. Otherwise, the generic names with and without
proper suffixes (either -qt5 or -qt4) are checked in the PATH.
This means that --with-qt-dir=qtdir should be used only if the tools
are not in the PATH, or qtdir/bin/{moc,rcc,uic} are the right versions
for the desired Qt. In any case, it is later checked that the selected
tools are the right ones and a warning is issued if there is a mismatch.
The test is stolen from cmake code.
Tested on:
* ubuntu 12.04 with g++ 4.6, clang 3.3 (with libstdc++)
* ubuntu 16.04 with g++ 5.3, clang 3.7 (with libstdc++) and clang 3.7
(with libc++)
The last combination fails, but it seems to be related to real bugs
(reported for debian), so this is OK.
The test file is stolen from cmake. The options tested are, from the
most desirable to the least desirable:
-std=c++14 -std=c++11 "" -std=c++0x -std=gnu++14 -std=gnu++11 -std=gnu++0x
It is expected that the result will not be correct for cygwin, but
this is fixable.
The split is now analogous to automake. The individual libs are handled
analogously to already handled boost.
automake config setting cmake config settings
--with-included-iconv -DLYX_EXTERNAL_ICONV=OFF
--with-included-zlib -DLYX_EXTERNAL_Z=OFF
--with--included-hunspell -DLYX_EXTERNAL_HUNSPELL=OFF
With this change, it is now possible to configure with --enable-qt5
and have make use "moc -qt=qt5" automatically.
This is done when the command qtchooser is available nd the desired Qt
version (qt4/qt5) is available.
This means that it is now possible to have qt4 and qt5 builds easily
on a same linux system.
A window manager could be configured such that to maintain a certain
stack order for the windows. It would be annoying that opening a new
file through menu brings up the window, so do this only if we are
loading a file through the lyx-server.
The line felt too thin.
Note: I am still sceptical with the principle of an increase at the rate of
1/200% instead of 1/100%.
Also, I am sceptical with changing painting dimensions to int when Qt supports
doubles for everything (see e.g. 463bd17d). If the goal is to force
integer-width solid lines then one could try to disable antialiasing on Qt's
side.
I think the painter should move in the other direction, towards more doubles and
fewer ints. For instance, for Hi-DPI, Qt could probably take advantage of the
increased precision even without AA. (Then one would have to fix the problem
regarding uneven lines, mentioned in the above commit, in another fashion.)
