| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit, we only added pressed keys to the search string if
they have no other meaning. This means that files containing a Space in
their name could not be searched because Ctrl+Space toggles the
selection state of the current item, and Space alone selects the
current item.
After this commit, Space is added to the search string if
(a) the key press did not have any other effect, i.e., if Ctrl was not
pressed, and the current item is selected already, and
(b) a keyboard search has been started already (to prevent unexpected
effects when pressing Space accidentally - I think that it's rather
uncommon to have files whose names start with a Space - and to make
the unit test simpler).
I modified the unit test of KItemListController, which did not test
keyboard search yet. This uncovered a small problem in
KItemListController::slotChangeCurrentItem() when NoSelection mode is
used. It's not really relevant for anything that is executed inside
Dolphin, but I still fixed it to make the unit test happy.
BUG: 324479
FIXED-IN: 4.11.3
REVIEW: 113071
|
|
This fixes the problem that filtered child items in Details View may
reappear when switching the view mode and the clearing the filter.
BUG: 325344
REVIEW: 112962
FIXED-IN: 4.11.3
|
|
KFileItemListView notifies KFileItemModelRolesUpdater of changes of the
visible index range and the icon size with a delay, to prevent that
expensive operations are triggered repeatedly, and that scrolling feels
sluggish because the GUI thread is blocked by icon loading.
This patch ensures that the "long" delay of 300 ms is only used when
the zoom level is changed, and the "short" delay if only the visible
index range has changed.
Thanks to Christoph Feck for helping to analyze this problem!
BUG: 322093
FIXED-IN: 4.11.2
REVIEW: 112580
|
|
Take the style option vertical/horizontal margin into account
for the calculation of the new scroll offset.
Thanks to Frank for pointing out two other problems with "Page Up/Down" and providing
a better way to fix these problems. :)
BUG: 311099
FIXED-IN: 4.11.2
REVIEW: 112678
|
|
When sorting by, e.g., "Size", and the name is used as a fallback
because there are multiple files with the same size, the refreshItems
signal that is received when a file's name is changed either with the
dialog or outside the current view did not cause the view to be resorted
after commit d70a4811807776966c3241a72121242f4d1eaee8. This patch fixes
it.
BUG: 324713
FIXED-IN: 4.11.2
REVIEW: 112561
|
|
Makes Left/Right keys consistent with QLineEdit behavior.
BUG: 323946
FIXED-IN: 4.11.1
REVIEW: 112256
|
|
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
|
|
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
|
|
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
|
|
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
|
|
|
|
If the role editor loses focus, it considers the current renaming
operation finished, and tells DolphinView to rename the file. This is a
problem when changing the directory, because the URL change happens
before DolphinView receives the signal, which results in a file in the
new directory being renamed unexpectedly.
The solution is to establish the connection to the
slotRoleEditingFinished signal only when the "rename inline" editor is
opened, and disconnect it when renaming is finished or canceled or the
URL changes.
BUG: 319912
FIXED-IN: 4.10.5
REVIEW: 110908
|
