On Linux and Mac OS, this action brings the LyX window into focus.
Such behavior is not allowed by Windows OS so instead the color of
the taskbar entry is changed to indicate that the window has changed
in some way.
The action is hidden in the shortcuts menu because it would make
sense to assign a shortcut to it. The only way to execute shortcut
would be if the LyX window is already activated.
lyx-activate will be used (see next commit) to allow the PDF viewer
to switch to LyX after executing a reverse search.
* New constant LYXFILE_LAYOUT_FORMAT in src/TextClass.cpp. This determines the
layout format corresponding to the current lyx file format.
* The Local Layout pane is changed so that the "Convert" button does not convert
to the internal layout format but to the current lyx file format, to make sure
that the file does not become unreadable with a specified earlier version of
LyX.
* If LYXFILE_LAYOUT_FORMAT == LAYOUT_FORMAT then LyX behaves as before. This is
the value defined in master.
A static local variable is guaranteed to be initialized only once, and in time.
Lambda expressions can be used to perform complex initialization of those static
variables on the spot.
(starting from: gcc >= 4.8, msvc >= 2015)
Prevent setRange() from causing a recursive call to scrollTo(). Reduces three
calls of scrollTo() to one call for all scrolling functions of the scroll bar
(e.g. clicking on the arrow, dragging, or clicking somewhere on the scrollbar).
Before this commit, in the paths preferences tab if you put a
relative path, LyX would convert it behind the scenes to an absolute
path by evaluating the relative path with respect to the working
directory of the LyX instance where the preference change is taking
place. This seems confusing because (1) it is done behind the scenes
(after the preferences dialog is closed) and (2) if the user chooses
to enter a relative path, the safest thing to do is to preserve it
as a relative path, instead of making the assumption that the user
intended for it to be expanded to an absolute path.
An explanation of how relative paths are handled is given at the
bottom of the paths tab. Note that the height/width of the
preferences window is not changed as a result of adding this
explanatory comment because the height of the preferences dialog is
already stretched by other tabs.
This commit improves consistency in the sense that the behavior of
LyX is now the same when a relative path is specified in the
preferences dialog as when it is manually specified in the
preferences file. Before, if the preferences file were manually
edited and a relative path were inserted, the next time the user
made a change to preferences with the GUI (even if the preference
change was a different preference, e.g. instant preview), the
relative path would be silently converted to an absolute path,
evaluated with respect to the working directory of that instance.
Beyond improving clarity and consistency (IMO), this commit allows
for a new feature to be implemented of using relative paths in the
paths preferences. For example, the user may now enter '.' as the
"Working directory" path and now whenever they start LyX from a
directory and create a new file, the default location of the file
will be the directory from which they started LyX, instead of the
user's home directory which is LyX's default and is less intuitive.
No prefs2prefs work is needed because if a relative path were
entered in the preferences dialog before this commit, it was
converted to an absolute path before being stored in preferences. If
a relative path were specified by manually editing the preferences
file, then (unless the path were already automatically converted to
an absolute path by a GUI preferences change, as described above)
the behavior will be the same (the path will be treated as a
relative path).
For related discussion, see the lyx-devel thread here:
https://www.mail-archive.com/search?l=mid&q=20160616003010.bnymtcouar7g55ti%40cotopaxi
This commit removes the last use of lyx::support::expandPath() in
LyX's sources.
The Qt documentation states that tabAt() returns -1 if the position
is not over a tab. This behavior has been consistent since Qt 4.3
[1]. This commit's improvement likely makes the code faster in two
ways:
(1) we do not need to loop through potentially all tabs
(2) we only need to look up the tab index corresponding with one
position
posIsTab() is not currently used intensively so no practical gain in
speed is achieved, but it protects against future use.
[1] https://doc.qt.io/archives/4.3/qtabbar.html#tabAt
This is the default behavior of Chromium and Firefox. The main
appeal is that instead of having to precisely click on the 'x' to
close a tab, one can more easily middle-click anywhere in the tab.
The tab is closed if the middle button is pressed on a tab and is
relased on the same tab. After pressing, the user may move the mouse
over other tabs but as long as they move it back to the tab where
they initiated the press before they release, the close will
execute. This is how the feature works in Chromium and Firefox.
Nothing is done if the user middle-clicks on the blank part of the
tab bar. This is consistent with Chromium. Firefox, on the other
hand, opens a new tab. In LyX one can already double-click the blank
part to open a new tab, and in feedback from lyx-users [1] most
expected and desired that nothing be done in this case.
[1] https://www.mail-archive.com/search?l=mid&q=20160720063306.6fyarf3kywexbxvd%40steph
A chunk of code in an event handler seems to be unnecessary to me
because the event that the situation handles never makes it this far
in the event handling hierarchy. I'm not sure why this is, and thus
I'm not sure if this is true in all cases (e.g. Qt version) and if
it will be true in the future so I leave this code for now.
* Fix bug #10261 : KDE smartly adds conflicting accelerators.
* Prevent bugs like #9495 in the future.
Issues (non-regression):
* It does not appear possible to prevent Ubuntu's Unity from grabbing the
accelerators for the menus. For instance Alt+A still opens _Affichage in the
French localization.
Add a new checkbox "Save transient properties" to the "Output" panel in the
document properties dialog (now renamed as "Format").
This provides the front-end for the change at 5c2d04999.
is output when a branch is NOT activated. Fixes bug #7698.
At the moment, inversion is controlled through the branch settings
dialog. There is no provision for inserting inverted insets directly,
or for changing them from the context menu. Both of these could be
done, of course. The latter would need LFUN_BRANCH_TOGGLE_INVERTED.
The differentiation of "xetex" and "platex" is not needed here,
is ambiguous and confusing (see #10013). The code that relies on
it can/should get its information otherwise.
Furthermore, polyglossia-exclusive languages now also work with
LuaTeX, since we support LuaTeX + polyglossia.
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
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.
It is not possible to use opacity effects (such as drawing an antialiased line
to strike diagonally through an inset), until the painter is fixed so that it
does not redraw repeatedly over the same spot (otherwise, the usual aritfacs
appear).
For now, pixellated lines are OK.
* Justification and nicer line breaks.
* Much nicer tooltip for lists of bibliographical references.
* Removed unnecessary iterated copies of the string buffer in
InsetText::ToolTipText() which looked bad. This function used to be costly
(cf64064), maybe it is quicker now.
After the previous commit, tooltip in the outliner are formatted automatically,
along with the other tooltips. A previous commit had already removed the
expensive call to tooltipText() that, although it gave a better rendering, was
very expensive (cf64064). This patch finishes to remove the custom tooltip
from the model data in the outliner.
(It would be nice to reintroduce a tooltip based on tooltipText(), but there
seemed to be a consensus that in that case one would prefer a less expensive
approach that computes the tooltip on the fly.)
* The tooltips in the list of modules now include the names of the modules.
* The tooltips of modules more consistent across the widgets.
* Sort the list of modules according to the locale (i.e. "É" comes before "F").
* Replace a hand-made sentence boundary finder by Qt's.
* New function formatToolTip(QString):
Format text for display as a ToolTip, breaking at lines of a certain
width. Note: this function is expensive. Better call it in a delayed manner,
i.e. not to fill in a model (see for instance the function
ToolTipFormatter::eventFilter).
* Install a global event filter that formats tooltips on-the-fly
Inspired from
3793fa09ff
but much improved.
When is formatToolTip called automatically? Whenever the tooltip is not already
rich text beginning with <html>, and is defined by the following functions:
* QWidget::setToolTip(),
* QAbstractItemModel::setData(..., Qt::ToolTipRole),
* Inset::toolTip() (added in one of the subsequent patches)
In other words, tooltips can use Qt html and the tooltip will still be correctly
broken. Moreover, it is possible to specify an entirely custom tooltip (not
subject to automatic formatting) by giving it in its entirety, i.e. starting
with <html>.
The main thing it does is integrate mouse-modifiers into the
FuncRequest machinery. Previously, these had to be passed
separately, which led to some ugly function signatures.
There was also an unnecessary form of the constructor, which
can now be removed.
No change of behavior is intended.
The only exceptions are:
- The purpose of the header is to drag in the used symbol, e.g. unique_ptr.h
- The used symbol is inside a class or a namespace other than lyx
The reason for this is that global 'using' statements effectively forbid to
use the used symbols in any other namespace in the whole program, since simply
adding or removing an #include of the corresponding header subtly changes the
name lookup. The namespace lyx is sort of global, so it should not have these
statements either.
This is a mechanical replacement. For now it seems that unique_ptrs are
essentially used for exception-safety. More could certainly be done to clarify
pointer ownership in general.
As discussed on the list. If no C++11 compiler is found configuration stops
with an error. There are now unneeded parts of boost, the will be removed in
a second commit.
Qt only supports SVG 1.2 tiny, so we prefer to convert on our own if an
explicit converter is defined and the converter cache is used (otherwise
the conversion would be too expensive).
Some qt versions report both "jpeg" and "jpg" as loadable file extensions.
In this case the jpg format was added twice previously. This does not happen
anymore with the new code, and it works as well if only "jpg" or only "jpeg"
is reported.
It is wrong to assume that direction is left-to-right when no indication exist.
Add a new enum with values LtR, RtL and Auto to be used as argument of
the private text() methods. When direction is Auto, let Qt decide how
the string shall be layed out.
Fixes bug #10169.
TocModels::reset() in GuiView::structureChanged() collapses the TocWidget, and
therefore requires an update right after, which was missing.
In fact, profiling TocWidget::updateView() shows that delaying the update is
good only for fast keypresses (essentially movement). It costs 5% of a
char-forward operation in a document with approx. 100 table of contents
items. The update optimisation has been rewritten to take this data into
account.
* remove optional arguments to the helpers that use a FontInfo
* add a textwidth argument to the text() methods that are used by rowpainter.
Now textwidth is only computed if a null value was passed to the
text() method. This means that in the use case of rowpainter, no
textwidth needs to be computed.
The computation of the width of the button was wrong. If <--> stands for TEXT_TO_INSET_OFFSET/2 spacing, and if `[]' marks the button's limits, then the intent is
<-->[<-->button text<-->]<-->
Therefore the physical grey rectangle width is
width - Inset::TEXT_TO_INSET_OFFSET
With this change, the spacing on the right of the button is not larger than the left one.
Fixes bug #10147.
The old name would be confusing wrt setSelection(), which does additional checks.
This one is a pure acessor, and the more complete methods are
* setSelection(), which avoids empty selections
* clearSelection(), which resets anchor, and sets word selection and mark more to false.
Most of the code should use these two instead of selection(bool), but this is for later.
