A more radical approach to inset background painting
Now by default all insets paint their own background when needed. This
means that 63cf3297 and part of 9940acc5 can be reverted.
To avoid extra painting, background drawing is disabled for
InsetCommand and InsetCollapsable. These insets draw background as
part of their normal drawing activity.
This will avoid drawing artifacts with InsetNewpage, InsetVSpace and
probably some others.
Scott Kostyshak [Tue, 9 Aug 2016 16:53:56 +0000 (12:53 -0400)]
Foils.lyx: fix output of author
By moving date and author above the standard layouts, author is now
output in the PDF and the terminal error from LyX about mixing an
InTitle layout with non-InTitle layouts is gone.
Scott Kostyshak [Sun, 7 Aug 2016 17:31:41 +0000 (13:31 -0400)]
Fix dviluatex exports of Sweave/knitr/Lily/noweb
After the fix at fe06ef0e, several converter chains to DVI
(dviluatex) were broken because they had previously gone through an
incorrect link in the chain.
This commit adds converters for the above formats to dviluatex and
fixes the following ctests:
Richard Heck [Fri, 5 Aug 2016 02:43:17 +0000 (22:43 -0400)]
Fix XHTML export of German Additional Features manual.
There was an oddity in the manual that exposed a problem with the
test for the "special case" of an inset all by itself in a pargraph.
If a font change is applied to that inset, we still need to open the
paragraph.
Guillaume Munch [Thu, 4 Aug 2016 12:30:47 +0000 (13:30 +0100)]
Partially revert "Replace static with thread_local when used for caching"
As noticed by Stephan, clang on Mac is nowhere near to support thread_local for
some reason:
http://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports
It does not look realistic to me to provide a configure-based alternative. The
solution is to not use thread_local until it is reasonably supported on
Mac. According to sources, this means requiring Xcode >= 8.
Include all [scr]article styles in beamer article layouts.
File format change. On format reversion, we need to put some extra code
in the local layout that emulates the 2.3 behavior.
Simply Input'ing the respective layouts is unfortunately not enough,
due to the insertion order.
Scott Kostyshak [Thu, 4 Aug 2016 05:25:36 +0000 (01:25 -0400)]
Activate LyX window after reverse search (#10196)
"lyxclient -g" now calls the just implemented lyx-activate (see
previous commit) after server-goto-file-row. This allows the PDF
viewer to switch to LyX after executing a reverse search.
Scott Kostyshak [Thu, 4 Aug 2016 05:20:14 +0000 (01:20 -0400)]
New LFUN lyx-activate to focus LyX window
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.
Enable to specify the target format for converting the local layout
* 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.
It is currently called on hundreds of files: settings, layouts, icons, cached
graphics files (incl. graphics from files that are not opened on startup).
According to callgrind, fixing the FIXME comments could speed up startup by more
than 30%.
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).
Richard Heck [Sun, 31 Jul 2016 06:52:30 +0000 (02:52 -0400)]
Add 'dir="auto"' to the body tag for XHTML export. This should take
care of much of what we need to do for RTL languages. It does not
take care of inline language changes, probably.
Scott Kostyshak [Fri, 29 Jul 2016 17:15:41 +0000 (13:15 -0400)]
Remove the now unused lyx::support::expandPath()
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).
Scott Kostyshak [Fri, 29 Jul 2016 17:13:55 +0000 (13:13 -0400)]
Rel. path in paths prefs preserved as rel. paths
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.
Scott Kostyshak [Fri, 29 Jul 2016 17:06:49 +0000 (13:06 -0400)]
Improve implementation of TabWorkArea::posIsTab()
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.
Cmake build: Make sure that a sequence of commands to recreate layouttranslations failes
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.
Scott Kostyshak [Wed, 13 Jul 2016 06:42:35 +0000 (02:42 -0400)]
Close a tab on middle-click (#10288)
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.