| Age | Commit message (Collapse) | Author |
|---|
|
When the name of a file is too long to be shown inside the maximum
number of lines, the last line is elided. However, there were several
problems before this commit:
(a) "lastTextLine", which contains the text to be elided, was not
assigned the complete remaining text, but only the part that would
be put into the last line if there were more lines following. This
may be less than what would fit into the line because we try to not
break the text at random points.
(b) QFontMetrics::elidedText() was not given the width that is available
for the last line (that would be maxWidth), but only the width that
would be occupied by the text if there were more lines following
(line.naturalTextWidth()).
(c) The variable "nameWidth", which is required to calculate the QRectF
that is reserved for the name, was not updated correctly.
The result is that the text was sometimes trucated too early (especially
if there would be a line break early in the text if we had more lines
available), that there may be insufficient space to show the "...", and
that the hover/selection rectangle might be too narrow.
BUG: 304558
BUG: 321882
FIXED-IN: 4.11.1
REVIEW: 112265
|
|
resize (when changing the zoomlevel).
BUG: 310412
REVIEW: 112250
FIXED-IN: 4.11.1
|
|
|
|
KFileItem::determineMimeType() not only determines the mime type, but
also the icon. For folders, it looks for a .directory file inside the
folder, where a custom icon might be stored. This can take quite a bit
of time and cause the problem that some folder's type still appears to
be "unknown" when the view is shown.
We can work around this problem by caching the folder mime type in a
static QString and applying to to all folders, which can be identified
easily with KFileItem::isDir(),
BUG: 321710
FIXED-IN: 4.11.1
REVIEW: 111830
|
|
This should prevent crashes that can be caused if the view is closed in
a nested event loop that is run from the role editor.
BUG: 322969
FIXED-IN: 4.11.1
REVIEW: 111988
|
|
to avoid too much expensive resorting calls, in case of many refresh items signals.
Followup to patch 111146
CCBUG: 303873
CCBUG: 299565
BUG: 323789
FIXED-IN: 4.11.1
REVIEW: 111195
|
|
m_sizeHintCache.fill() in KItemListSizeHintResolver::clearCache().
REVIEW: 112179
|
|
|
|
KFileItemModel::setData() should not only cause a resorting when the
sort role is changed. The name is always used as a fallback if the sort
role of multiple files is equal, therefore, renaming a file can change
the correct order of the files even if the files are not sorted by
"name".
Unit test included.
BUG: 323518
FIXED-IN: 4.11.1
REVIEW: 111721
|
|
Storing values which are equivalent to default-constructed QVariants
does not make much sense because QHash::value returns the same value
even if the corresponding key is not found in the hash.
This commit reduces Dolphin's memory consumption in large folders by
up to 7.3% (tested a folder with 100,000 files in Details View) and
reduces the time required for loading a folder.
BUG: 323517
FIXED-IN: 4.11.1
REVIEW: 111922
|
|
The problem was that we drawed the overlays using KIconLoader, which can
be very slow, every time an item appeared on the screen. This commit
makes sure that not only the icon, but the icon including overlays is
cached in QPixmapCache. Therefore, the overlay drawing is done just once
for each icon+overlays combination.
For previews, the overlay drawing is done in KFileItemModelRolesUpdater
just after the preview is received.
BUG: 310662
BUG: 314339
FIXED-IN: 4.11.1
REVIEW: 111956
|
|
The problem was that items are removed from m_visibleGroups while
a QMutableHashIterator iterates over this hash, such that the iterator
can become invalid. The solution is to use a QHashIterator instead,
which takes a copy of the hash. Therefore, it is not affected if
m_visibleGroups is modified in any way.
BUG: 323248
FIXED-IN: 4.11.1
REVIEW: 111919
|
|
Sometimes when items are renamed, the order of the items in the
directory is not affected, but the groups still change (simple example:
with files a, b, c, e, rename "c" to "d"). At the moment, we always emit
the itemsMoved signal in such a case to make sure that the view is
updated. However, it would be preferable if this signal was not emitted
because it can trigger some quite expensive operations which are not
needed at all.
This commit introduces a new signal groupsChanged and modifies
KFileItemModel and KItemListView such that these classes make use of it.
Some unit tests for the new functionality are included as well.
Thanks to Emmanuel Pescosta for finding a latent bug in the code which
was triggered by this change and fixed in
998954db6d53999dfa75d380cbb4ca3111589f66.
REVIEW: 111808
|
|
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/
|
|
|
|
This small change saves a lot of CPU cycles when the items are resorted.
REVIEW: 111700
|
|
|
|
The problem was that the view heigt minus the header height was
subtracted from maximumScrollOffset() to determine the maximum value
of the scroll offset of the top of the view.
However, the top of the view is the part that is hiden behind the
header. Therefore, the full view height must be subtracted from
maximumScrollOffset.
The remaining bits of bug 319951 were fixed by other recent commits.
Thanks to Emmanuel Pescosta for helping to track down the problem!
BUG: 319951
FIXED-IN: 4.11.0
REVIEW: 111486
|
|
When items are removed, new items may become visible because of that.
This includes
(a) Items *behind* the removed range. KItemListView may try to create
their widgets at their "imaginary" old positions and move them to
the new position with an animation.
(b) Items *before* the removed range, if the deletion causes the view
to scroll up. In that case, the "imaginary" old position and the new
position was equal, but KItemListView still tried to determine the
"old" position by adding the number of removed items to the index.
The result was that the widgets were created at completely wrong
positions, and no animation was started to fix this.
Thanks to Emmanuel for helping to find the cause of this bug!
BUG: 302373
FIXED-IN: 4.11.0
REVIEW: 111630
|
|
The problem was that DolphinItemListView overrides the virtual function
onItemLayoutChanged() without calling the base class implementation.
Therefore, KStandardItemListView::updateLayoutOfVisibleItems(), which
calls initializeItemListWidget(), is never called.
This patch refactors the "change item layout"/"supports item expanding"
code a bit to make it more robust and fix the problem that the view
looks "messed up" when switching from Details View without expandable
folders to Icons View.
I'm only pushing this patch to master (going to be KDE 4.12).
The patch is a bit too intrusive for the KDE/4.11 branch for my taste
at this point of the release cycle, and the bug is not a real
showstopper. If it works well in master, one could consider backporting
it to a 4.11.x bug fix release.
Thanks to Emmanuel Pescosta for helping to analyze this issue.
BUG: 302703
REVIEW: 111632
FIXED-IN: 4.12.0
|
|
KItemListSmoothScroller::scrollTo(qreal position) did not check if
'position' is a valid value. Even if the view is scrolled to the bottom
already, it tried to scroll further and activated "smooth scrolling"
when the mouse wheel is used. Because it never got out of the "smooth
scrolling" state then, it got confused when changing the directory, and
restoring the correct scroll offset could fail.
BUG: 322212
FIXED-IN: 4.11.0
REVIEW: 111557
|
|
The code for painting the "empty header" was inconsistent with the
headers of the other columns, which is probably the reason why the other
styles got confused
a) No QStyleOptionHeader is used
b) Even if an empty header must be drawn, the last column is drawn with
the option QStyleOptionHeader::End.
According to Christoph, it still doesn't work with the Skulpture style,
but it seems that the patch does at least not make things worse.
BUG: 301800
FIXED-IN: 4.11.0
REVIEW: 111608
|
|
We really have to make nepomuk-core and nepomuk-widgets a hard
dependency in the framworks era.
|
|
because the nepomuk roles provider doesn't overwrite it when the property
value list is empty.
BUG: 322348
REVIEW: 111505
FIXED-IN: 4.11.0
|
|
Rather than loading many icons (without full mime type determination)
in advance, we make sure that an item has an icon just before it is
shown in the view. This makes sure that no "unknown" icons are shown
unnecessarily, and saves some resources.
REVIEW: 111396
|
|
If many item ranges are removed, KItemListView::slotItemsRemoved()
could take very long because it looped over all items after the first
removed one for every removed range, even if most of these items are
not visible at all.
This commit improves this by just looping over the visible items (whose
number is limited by the window size) for each range.
Test case (for very large N):
touch {1..N}.png
touch {1..N}.jpg
(wait until all files are shown in the view)
rm *.jpg
REVIEW: 111398
|
|
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
|
|
In Icons/Details (Compact) View, no layouting is necessary if the view
height (width) changes.
REVIEW: 111322
|
|
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
|
|
Since m_pendingItemsToInsert is a list of pointers now (and not a list
of KFileItems, as in the 4.10 branch), we have to delete all pointers
when clearing or destroying the model.
I think that no review request is necessary for this small and obvious
change.
CCMAIL: [email protected]
|
|
icon in Compact View and Details View mode.
BUG: 320899
FIXED-IN: 4.11.0
REVIEW: 111244
|
|
Added a hash table for target url to url mapping. So when the dir lister
sends us the target url as directory url, we can use the url mapping table
to get the right "Dolphin internal" directory url, which is the non-target url.
BUG: 306219
FIXED-IN: 4.11.0
REVIEW: 111252
|
|
When using Details View, only insert all pending items immediately if
new items are inserted which might be children of a pending item. Fixes
the problem that inserting the items in multiple bunches slows down the
folder loading.
Note that the cause of the slowness when inserting in multiple bunches
is that KItemListSizeHintResolver needs O(N^2) time in the worst case
for inserting N items into a model with N existing ones.
REVIEW: 111226
|
|
|
|
KFileItemModel::createMimeData.
BUG: 307336
FIXED-IN: 4.10.5
REVIEW: 111209
|
|
It is common for music files to have more than one artist
BUG: 321359
|
|
It is no longer required. In fact it hasn't been required since
nepomuk-core was introdcued.
|
|
Each time one uses any of the Nepomuk classes, an attempt is made to
connect to the database. This slows down the application since
connecting to Nepomuk is not so cheap.
BUG: 321299
|
|
|
|
The problem was that pressing the Shift key would reset the keyboard
search.
BUG: 321286
FIXED-IN: 4.11.0
REVIEW: 111102
|
|
This fixes the problem that the drop indicator might still be shown
after the drag&drop operation in the Places Panel is finished.
REVIEW: 111037
|
|
This removes some things that are obsolete after the recent commits:
(a) resolveNextPendingRoles() is not called any more when the preview
job is running.
(b) In applyResolvedRoles(), we always load the icon if it isn't known
yet. This ensures that every item has an icon.
REVIEW: 111012
|
|
If all icons for the visible items could be loaded in 200 ms, we
continue loading icons without mime type determination for all items
until the 200 ms are over. This reduces the risk that the user ever
sees "unknown" icons.
REVIEW: 111011
|
|
when the sorting role value is changed.
BUG: 299565
FIXED-IN: 4.11
REVIEW: 111146
|
|
We try to determine "final" icons, i.e., icons with known mime type,
for 200 ms. If this does not succeed, we at least load "fast" icons,
i.e., load the icons without determining the mime type.
REVIEW: 111009
|
|
width or 0px height, so the selected items can not be accidently
unselected when the rectangle width/height becomes 0px.
BUG: 320897
REVIEW: 111144
FIXED-IN: 4.10.5
|
|
This patch changes two things about the way we handle the preview jobs:
(a) Rather than passing a KFileItemList to startPreviewJob(),
remembering the leftovers in the member variable
m_pendingPreviewItems and then starting a new preview job for
these, we append items that need a preview to this member, and let
startPreviewJob() take its input from there. This simplifies the
code greatly.
(b) To prevent that we start preview jobs with just one item and also
that the GUI is frozen too long by startPreviewJob(), we take the
following approach:
* If the mime type of the first pending item is known, the function
has probably been called by startUpdating(), which has determined
mime types for the visible items already. startUpdating() has
also blocked the GUI, so we just take all items at the beginning
of the list with known mime type, and do not do any expensive
mime type determination in startPreviewJob().
* If the mime type of the first pending item is unknown, the
function has probably been called by slotPreviewJobFinished(). In
that case, we can afford to block the GUI for a short while, so
we determine mime types for 200 ms.
REVIEW: 111008
|
|
|
|
Before this commit, switching from, e.g., "Sort by Name" to "Sort by
Type" sometimes had no effect until the view was refreshed. The problem
was that the re-sorting was triggered before the type information was
actually added to the model.
BUG: 310705
BUG: 312014
FIXED-IN: 4.10.5
REVIEW: 111004
|
