The function is no longer used in LyX's sources (as of the previous
comit, 9b64d7bd) and is thus removed with this commit. Perhaps the
advantage this function had over other path functions we have has
disappeared over time (see e.g. 1a7b7f65).
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 commit documents the feature introduced at 4803c769, which
fixed#10288.
The User Guide already has a section on closing tabs, so this fits
in well.
Factored out the sequence into one cmake-script.
Previously it could happen that the python script failed, but the following
command was successfull and so the error was hidden.
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.
