This pane is responsible for horizontal excess size (at least in CZ
translation) of document settings panel. The reason is second encoding combo
which get very lengthy (there are actually 3 of them).
This patch moves them to separate line.
Beware, touching this panel is headache.
Qt Designer (5.15.2) does not know even how to load this ui
file correctly and it's impossible to move unicodeEncodingCO.
When breaking layout this CO is mysteriously deleted.
Finally I gave up and simply edited file in vim to get COs to the new row.
It turns out that LyX was using red as default color for the
inset button text since ever. However, due to the use of "inherit",
the default button text color was black in practice. This was so
until [897ee2ed/lyxgit], which made the label font not inherited
by default anymore. Hence, all insets that didn't specify a specific
label button color started using red as default color.
This commit restores the previous behavior and introduces the
possibility of modifying this default color.
Fixes bug #12771
This fixes the g++ 12 warnings below.
../../master/src/Converter.cpp:714:55: warning: possibly dangling reference to a temporary [-Wdangling-reference]
714 | Mover const & mover = getMover(conv.to());
| ^~~~~
../../master/src/Converter.cpp:714:71: note: the temporary was destroyed at the end of the full expression ‘lyx::getMover(lyx::Converter::to() const())’
714 | Mover const & mover = getMover(conv.to());
| ~~~~~~~~^~~~~~~~~~~
../../master/src/Converter.cpp:786:39: warning: possibly dangling reference to a temporary [-Wdangling-reference]
786 | Mover const & mover = getMover(conv.from());
| ^~~~~
../../master/src/Converter.cpp:786:55: note: the temporary was destroyed at the end of the full expression ‘lyx::getMover(lyx::Converter::from() const())’
786 | Mover const & mover = getMover(conv.from());
This is done at the end of the release cycle to avoid backporting issues.
The goal is to simplify development, since it was difficult to guess
in which file a given method could be found.
There is some effect on compilation time, but it is not too bad:
* before merge
lapinot: time make Text.o Text3.o Text2.o
CXX Text.o
CXX Text3.o
CXX Text2.o
real 0m32,504s
user 0m31,027s
sys 0m1,446s
lapinot: rm Text*.o
lapinot: time make -j8 Text.o Text3.o Text2.o
CXX Text.o
CXX Text3.o
CXX Text2.o
real 0m21,282s
user 0m32,661s
sys 0m1,424s
* after merge
lapinot: time make Text.o
CXX Text.o
real 0m26,731s
user 0m25,706s
sys 0m1,020s
Due to a macOS peculiarity, it is necessary to handle KeypadModifier.
We do it unconditionnally, although only macOS seems to be affected.
"Note: On macOS, [...] The KeypadModifier value will also be set when
an arrow key is pressed as the arrow keys are considered part of the
keypad." (https://doc.qt.io/qt-6/qt.html#KeyboardModifier-enum)
Related to bug #12572.
This is a follow-up to 5be391b2, which increased the space on
left/right of graphics inset. This extra space makes sense in normal
graphics editing, but is weird in the case of InsetInfo, which has its
own spacing.
Create a special tight graphics inset class, and use that for icons.
Qt 6.5.0 has dropped support for the QWindowsMime class
in favor of a new QWindowsMimeConverter class. They say:
"If you have implementations of QWindowsMime or QMacMime in Qt 5,
then those will almost directly translate to the new APIs but
require less boiler-plate code to register the converters with Qt."
This may be true, but in practice they break binary compatibility with
previous versions. If you used the QWindowsMime class until Qt 6.4 by
using boiler-plate code to register the converters with Qt, you now
need to modify the sources and recompile. Fantastic!
