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.
* 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.
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.
These were found by cppcheck:
Member variable 'x' is not initialized in the constructor.
The crash #9788 would not have happened if this had been done earlier.
Use the function support:truncateWithEllipsis() to shorten a docstring with
... at the end. Actually we use U+2026 HORIZONTAL ELLIPSIS instead of "..." when
automatically shortening strings. This is to be consistent with Qt's own
truncation and is much nicer on the screen.
This includes the bugs #9575 and #9572 regarding broken text elision in the
outliner.
Known issues (non-regressions):
* TocBackend::updateItem() should be rewritten to update all TOCs. (#8386)
* "..." should be replaced with … everywhere else on the interface (including
translation strings).
* We should prefer to rely on QFontMetrics::elidedText() to truncate strings
with an ellipsis whenever possible, or an equivalent for the buffer view
dependent on the font metrics. See the warning in src/support/lstrings.h.
If a compressed svg icon is present, load it instead of a png one.
Also introduce two more sizes (huge and giant icons) that should be
useful when using hires displays, as svg icons automatically scale
to the desired size without loss of quality.
This fixes the -geometry command line option and restores the
"Use icons from system's theme" checkbox in the preferences.
There is still code addressing Qt4 and xlib that has to be
audited. This code cannot be compiled with Qt5 because the
default backend is now xcb and not xlib. I have marked such
code with a "FIXME QT5" comment.
This implement horizontal scrolling of rows to allow editing insets
(math, tabular...) that are larger then the screen. The scrolling happens
as the cursor moves, in order to make sure that the cursor is always visible.
This effectively closes an 11 years old bug.
This feature is the result of the work of Hashini Senaratne as part of
Google Summer of Code 2013. The code has been cleaned-up for inclusion
and remaining bugs have been fixed.
Fixes bug: #1083.
[This commit is the output of the "horizontal scrolling" GSoC 2013
project, by Hashini Senaratne. The code has been cleaned up, some
variables have been renamed and moved from the Cursor class to
BufferView::Private. This is the base from which I (jmarc) will polish
the feature for landing on master.
Below is the original commit log of Hashini, updated to reflect the
changes that have been done.]
This feature also applicable for other insets; graphics and labels.
This implementation is capable of scrolling a single row when reaching
its content which is beyond the screen limits, using left and right
arrow keys.
The attribute 'horiz_scroll_offset_' introduced in the
BufferView::Private class plays a main role in horizontal scrolling of
the wide rows that grow beyond the screen limits. This attribute
represents by how much pixels the current row that the text cursor
lies in should be get scrolled.
The main logic that is responsible for drawing the scrolled rows is
within the BufferView class, BufferView::checkCursorScrollOffset.
* The main logic is called via BufferView::draw.
* What this does is set the horiz_scroll_offset_ attribute in in order to
show the position that the text cursor lies in.
* To make sure that BufferView::draw gets involved when Update flag is
FitCursor, necessary changes are made in BufferView::processUpdateFlags.
Basically what the logic that used to set the horiz_scroll_offset_
does is,
* The row which the text cursor lies in is identified by a
CursorSlice that points to the beginning of the row. This is the
'rowSlice' variable used in BufferView::checkCursorScrollOffset. Acessors
are added to obtain this variable. Here row objects were not used to
identify the current row, because it appears that row objects can
disappear when doing a decoration update for example. This means that
comparing row pointers is not a good idea, because they can change
without notice.
* Stop calculations of horiz_scroll_offset_ variable, if metrics have not been
computed yet. Otherwise the calls to TextMetrics::parMetrics, calls
redoParagraph and may change the row heigths. Therefore vertical scrolling
feature may get disturbed. This is avoided.
* Using BufferView::::setCurrentRowSlice resets horiz_scroll_offset_
when changing cursor row. This is done in order to prevent unwanted
scrolling that happens when changing the selected row using up and
down arrow keys.
* Recompute inset positions before checking scoll offset of the row, by
painting the row insets with drawing disabled. This is done because the
position of insets is computed within the drawing procedure.
* Current x position of the text cursor is compared with the
horiz_scroll_offset_ value and the other variables like row.width(),
bv.workWidth(). Compute the new horiz_scroll_offset_ value in order
to show where the text cursor lies in. The basics conditions that we
check before recomputing it are, if the text cursor lies rightward to
the current right screen boundary, if the text cursor lies leftward
to the current left screen boundary, if the text cursor lies within
screen boundaries but the length of the row is less than the left
boundary of the screen (this happens when we delete some content of
the row using delete key or backspace key).
* Change update strategy when scrooll offset has changed. This allows to
redraw the row when no drawing was scheduled. By doing so, it was
possible to redraw a wide row when moving to the leftmost position of the
wide row, from the leftmost position of the row below, using the left
arrow key.
In TextMetrics::drawParagraph it is checked whether the current row is
what is drawing now. If it is so, the value used to the x value of the row
for drawing is adapted according to BufferView::horizScrollOffset.
The method used to pass boundary() was fixed to get row when cursor was in
a nested inset. This matter is considered in Cursor::textRow and it is
modified accordingly.
GuiWorkArea::Private::showCursor() is modified to show the cursor position
in a scrolled row.
Introduce the concept of pixel ratio: the ratio of physical and device independent pixels.
This is useful for rendering of content on Retina-displays of Mac hardware with high resolution.
Qt has real support for this starting with Qt5 - therefore it has to be compiled conditionally.
This change uses some work of Marcelo Galvão Póvoa, thank you.
FileName::tempName() created a new temp file name by using qt to create a
temporary file with a unique name, and then deleting that file and returning
the name. This was unsafe, since other processes or even other threads of the
running LyX could create files with the same name between deletion and then
using the temp name.
This is fixed by using the TempFile class instead. As a side effect, a few
cases where the temp files were not deleted after usage were fixed as well.
The only place that is still unsafe is createTmpDir().
for possible thread conflicts, of the sort Georg resolved at
6a30211f. I have made static variables const where possible,
and marked cases that looked potentially problematic with the
comment:
// FIXME THREAD
Many of these definitely are vulnerable to concurrent access, such
as the static variables declared at the start of output_latex.cpp.
Suppose, e.g., we were outputting latex and also displaying the
source of a different document.
I'd appreciate it if others could grep for "FIXME THREAD" and see
if some of these are harmless, or what.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
* some functionality is in new modules now
new header locations and library names: QtConcurrent and QtWidgets
* method setResizeMode is renamed to setSectionResizeMode
* deprecated QAbstractItemModel::reset() is dropped now
* platform specific code like QApplication::syncX() is not common anymore
* QString::fromAscii() is dropped now
* some QDesktopServices methods has been moved to QStandardPaths
When there is a single document open, the tabbar gets hidden. The only and selected tab is still visible though as a break in the line delining the tabwidget. To fix this we paint the tabwidget ourselves and remove the presence of the hidden tab.
If no mask is supplied or the mask is attached to the end of the filename, we end up with unexpected names like
<system-temp-dir>\lyx_tmpdir.qHp780.vcr780_<mask>
instead of a temporary file in the lyx temporary directory like
<system-temp-dir>\lyx_tmpdir.qHp780\<mask>.vcr780.
This option is set to true by default as this is the most widespread use case.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40515 a592a061-630c-0410-9148-cb99ea01b6c8
I also added 2 FIXME where we should not call GuiView directly.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39948 a592a061-630c-0410-9148-cb99ea01b6c8
