Change KeyMap::getBinding to return FuncRequest::prefix in this case.
Add handling of this case in PrefShortcuts::validateNewShortcut.
What does not seem to work is that if, for example, accent-acute is
bound to M-s (which is a prefix for size-related bindings), and then
the binding is removed, the functions are not visibly restored.
Part of bug #10131.
The help page of int QMessageBox::exec() (https://doc.qt.io/qt-6/qmessagebox.html#exec) says:
When using a QMessageBox with standard buttons, this function returns a StandardButton value indicating the standard button that was clicked.
When using QMessageBox with custom buttons, this function returns an opaque value; use clickedButton() to determine which button was clicked.
This value is computed for the metrics of *every* Mathdata and hotspot
says that it counts for 9% of total on math-heavy "branch-test.lyx"
file. I am not sure that real world agrees with that, but profiling
shows that Qt itself does not cache the value.
Part of reinvestigation of #12297.
Otherwise we get the following warning:
src/frontends/qt/InsertTableWidget.h:44:7: error: 'hideEvent' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
void hideEvent(QHideEvent * event);
^
Amends ca5a75b2.
For some reason, the code that should have been put in
updateCaretGeometry() went to resetCaret(). I do not see how that made
sense.
I am not totally sure what the consequences of the patch are, though.
It just "looks right".
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.
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.
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!
