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.
