| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Unfortunately licensedigger does not strip the trailing * characters.
While at it, use a common style for all source files.
|
|
Summary:
Dolphin currently scrolls by the height of three items at a time per "step" when
using a scroll wheel. Because item height is highly variable, this leads to scroll
speed being inconsistent between views, and generally far too fast when using
icon view with icons larger than 22px size.
This patch makes the size of the scroll step based on the text label rather than the
icon size just like D25683, ensuring that the scroll speed does not vary and become
super fast when using large icons in particular.
It also reverts 90beb4a5e37b887caad1e767046a42dad0af1ab3, which is no longer needed.
BUG: 386379
FIXED-IN: 19.12.1
Test Plan:
Use a mouse with a scroll wheel and scroll in Dolphin item views with list view,
details view, icon view, etc, using different item sizes. Speed should be
consistent in all views now, and also feel consistent with other KDE apps.
Also try with multiple scale factors to make sure the behavior does not change.
No change with high-resolution two-finger touchpad scrolling.
Reviewers: #dolphin, elvisangelaccio
Reviewed By: #dolphin, elvisangelaccio
Subscribers: ahiemstra, lots0logs, anthonyfieroni, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D19190
|
|
GIT_SILENT
|
|
Summary: I used CLion inspection to hunt all unused #include
Reviewers: #dolphin, elvisangelaccio, markg
Reviewed By: #dolphin, elvisangelaccio, markg
Subscribers: bcooksley, markg, elvisangelaccio, #dolphin
Differential Revision: https://phabricator.kde.org/D10985
|
|
Summary:
CCBUG: 386379
after recent highdpi patches on scrolling that delegated it
completely to the scrollbar, based upon the scrollbar singleStep
setted to the tallest of the items in the view.
tough this makes scrolling way too fast, and on folders where just
few filenames are longer than most we can get a single scrolling
step almost double the number of lines configured in the
mouse kcm.
Using the shortest item instead of the tallest mitigates this problem
making it a bit more usable
Test Plan:
tested on different folders in different view modes both with
mouse and touchpad
Reviewers: #dolphin, broulik, ngraham
Reviewed By: #dolphin, ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10102
|
|
Commit f688bcd1f1 fixed slow scrolling with xf86-input-libinput on DolphinView.
However the commit also exposed a bug in the Dolphin scrolling
algorithm, which was previously hidden. This resulted in slow
scrolling in dock panels (Places and Folders), with both
xf86-input-evdev and xf86-input-libinput drivers, as well as libinput on
Wayland.
KItemListContainer::updateScrollOffsetScrollBar() relied on the view's
itemSize() method to compute the scrollbar's singleStep, but this QSize
was invalid for the dock panels' views.
We use a new itemSizeHint() method instead, which is always valid and
also adapts to the current icon size set in the view.
BUG: 365968
FIXED-IN: 16.12.0
REVIEW: 129409
|
|
By separating the width and height info, we can save some unnecessary
overhead in terms of memory and CPU cycles, and make the calculation of
the height of a row (or the width of a column in Compact View) a bit
simpler.
To achieve this, this patch extends the concept of "logical rows"
(which are actually columns in Compact View) to "logical width" and
"logical height" (which is the actual height and width, respectively, in
Compact View). The distinction between rows/columns and "logical"
rows/columns may be a bit confusing, but the confusion is already in the
current code, and I hope that it will be mitigated a bit by prefixing
the corresponding variables with "logical".
REVIEW: 118454
|
|
The speed up is really small, but theses changes are mostly straightforward and make the code a bit nicer - break
the KStandardItemListWidgetInformant::itemSizeHint beast into three smaller functions.
FIXED-IN: 4.13
REVIEW: 112979
|
|
m_sizeHintCache.fill() in KItemListSizeHintResolver::clearCache().
REVIEW: 112179
|
|
The function assumes implicitly that the moved range always starts with
the index 0. This is indeed the case at the moment, but it might make
sense to change that in the future. This commit prevents that we get an
out of range problem then.
Thanks to Emmanuel Pescosta for finding this problem, see
https://git.reviewboard.kde.org/r/111808/
|
|
It's quite expensive to re-calculate them, so we should better just move
them to the correct position, rather than throwing them away.
REVIEW: 111399
|
|
This was the root cause of bug 317827. The assert tried to make sure
that we never access KItemListSizeHintResolver from
KItemListViewLayouter inside the loop over the item ranges. This would
be dangerous because it might be in an inconsistent state - the removed
item ranges were removed step by step, so accessing the item size hints
before the operation was finished could lead to wrong results.
The solution is to insert/remove all item ranges immediately. A nice
side effect is that there are no sources of O(N^2) complexity in
KItemListSizeHintResolver any more if many item ranges are
inserted/removed.
BUG: 317827
FIXED-IN: 4.11.0
REVIEW: 111382
|
|
If the elements are larger than a pointer, QList does not store the
elements themselves, but pointers to them in a contiguous block of
memory. This wastes quite a bit of memory. This can be prevented easily
by using QVector instead.
REVIEW: 111304
|
|
- Move all private headers from the kitemviews-directory into
the 'private' subdirectory.
- Get rid of DolphinDirLister and just use a directory-lister
internally in KFileItemModel.
- Minor interface-cleanups for signals
|
