| Age | Commit message (Collapse) | Author |
|---|
|
More compile-time safety. Tests still pass.
This also fixes a krazy warning about "normalised signal/slot
signatures".
|
|
|
|
Commit 6dcbb8127c introduced the isHidden role, update the test
accordingly.
|
|
This is merge of #128964 and #128942. This will impelement changing the "Date" field to "Modified" and allow a new "Accessed" time field to be available. This also includes changes to update configuration files.
REVIEW: 129077
|
|
This bumps the minimum Qt version to 5.5 (because of Q_ENUM usage).
REVIEW: 129604
|
|
|
|
present, because KFileMetaDataWidget is in KDELibs4Support)
Reviewed-By: Vishesh Handa
|
|
pointer yet
|
|
All tests passed!
|
|
QUrl &url, bool delayedMimeTypes = false);
|
|
|
|
This commit is analogous to 5cf8941ac789e47da70fe466033f45df9af1a3fa,
but the problem existed since the frameworks port was started and was
not obvious because the QString -> KUrl/QUrl port was done implicitly
when calling KIO::rename(oldPath, newPath, KIO::HideProgressInfo).
REVIEW: 120941
|
|
These were caused by 86e31084ced8ba4875a6128f91ec2ca3d6df7a31 - note
that the correct replacement for KUrl(fileName) is
QUrl::fromLocalFile(fileName), and that calling the const function
urlA.adjusted(QUrl::RemoveFilename) only has an effect if the return
value is taken.
|
|
REVIEW: 120650
|
|
|
|
When opening the URL "man:", there are multiple items with the same
name (for example, _exit is shown twice here). When opening a new tab,
the kioslave reports some items as deleted (I have not quite understood
why). The problem is that it reports some of the duplicate items twice
in the list of deleted items. This confused KFileItemModel and
corrupted the internal data structures, and finally, caused a crash.
The fix is to remove all duplicates from
KItemRangeList::fromSortedContainer(const Container& container).
New unit tests included.
BUG: 335672
REVIEW: 118507
FIXED-IN: 4.13.2
|
|
Before this patch, any (direct or indirect) children that might have
been in m_pendingItemsToInsert, i.e., that were not inserted into the
model yet because KDirLister had not finished listing the directory
yet, would be added to the model later without a proper parent. This
could cause a crash later on.
CCBUG: 332102
FIXED-IN: 4.13.2
|
|
The test verifies that creating the mime data for a child of an expanced
folder does not cause a crash. The regression happenened in the master
branch, but it doesn't hurt to have the test also in KDE/4.12.
CCBUG: 329119
|
|
This fixes the problem that the new file name is not shown in the view
if an item is renamed while it is filtered.
BUG: 329118
FIXED-IN: 4.12.1
REVIEW: 114459
|
|
Since Dolphin 4.11, we store not only KFileItems, but also the
corresponding ItemData struct for filtered items. This is required for
keeping track of the parent-child relationships, and has the nice side
effect that the ItemData need not be re-determined when the items are
shown again.
However, this can become a problem if the visible roles or the sort role
change while some items are filtered.
This is fixed by is fixed by clearing the QHash "values" for the
filtered items if the visible roles change. The hash will be
re-populated with all requested data as soon as the items are shown
again and the data(int) method of the model is called.
Moreover, before the items are inserted into the model after filtering,
we have to make sure that the sort role "Permissions"/"User"/etc. is
present in the hash "values". This is achieved by factoring out the code
that currently does this job for new items in createItemDataList() into
a new function, and calling this in insertItems(), because the same
treatment is required for the previously filtered files.
BUG: 328791
FIXED-IN: 4.12.1
REVIEW: 114266
|
|
When we remove items from the model, we called the function
KFileItemModel::removeItems(const KFileItemList&, RemoveItemsBehavior).
This function then looked up the indexes of the items using the hash
m_items. This is wasteful in the situations when the indexes of the
removed items are known in advance (like when an expanded folder is
collapsed in Details View), and it can cause trouble if one item is
contained in the model multiple times (can happen when searching, and a
file both matches the search and is a child of a folder that matches
the search). Even if expanding folders in the search results list might
not be particularly useful most of the time, it makes sense to make the
model more robust to prevent crashes and other unexpected behavior in
such situations.
This patch makes the following changes to achieve that goal:
* Change the argument of removeItems() from KFileItemList to
KItemRangeList. To make this work, the "look the indexes up in
m_items" code is moved from that function to slotItemsDeleted(). In
the other places where removeItems() is called, the indexes are
calculated directly (which is not more difficult than determining the
removed items as a KFileItemList, if one considers that we needed the
function childItems(KFileItem) for that, which is not needed any more
with this patch).
* Also removeFilteredChildren() takes a KItemRangeList now. Rather than
putting the parent KFileItems into a QSet for O(1) lookup (which
prevents O(N^2) worst case behavior for the entire function), it uses
a QSet<ItemData*> now, which should even be more efficient (hashing a
pointer is cheaper than hashing a KFileItem/KUrl).
BUG: 324371
BUG: 325359
FIXED-IN: 4.12.0
REVIEW: 113070
|
|
|
|
This prevents a possible regression that would have happened with the
first version of https://git.reviewboard.kde.org/r/112725/
The problem was that isChildItem(int index) would return "false"
incorrectly when the QHash for that item was not initialized yet. The
grouping code would then try to read the "text" from the empty QHash,
which yielded an empty QString, and then accessing the first character
of that string caused a crash.
|
|
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
|
|
|
|
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
|
|
The most recent commit from the KDE/4.11 branch (new unit test) had to
be modified slightly due to the changed signal emission when resorting
the model changes only the groups, and not the order of the items
(groupsChaged instead of itemsMoved).
|
|
This unit test will hopefully prevent regressions in the future. It is
the first part of https://git.reviewboard.kde.org/r/112561/.
|
|
The idea is that we no longer assume that the "expandedParentsCount"
for each item will be stored in the QHash. It is only accessed for
items which are expanded, and which are not top-level items (i.e.,
which have an expandedParentsCount > 1).
Some unit tests are added to improve the coverage of the affected code.
REVIEW: 112562
|
|
|
|
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
|
|
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
|
|
Hopefully, this will prevent regressions in the future.
REVIEW: 111807
|
|
The 500 ms timeout before items are resorted does not make much sense in
the unit test. Removing this delay makes the test run much faster.
|
|
|
|
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 an item is moved out of an expanded folder, the model receives the
dir lister's refreshItems signal for the folder. The method
retrieveData() then updates the folder's properties. This commit makes
sure that the 'isExpanded' state is not touched by retrieveData(). A
side-effect is that the 'isExpanded' role is not initialized to 'false',
but this does not matter because trying to read a non-existing role from
the QHash<QByteArray, QVariant> yields a default-constructed QVariant,
which evaluates to 'false'.
BUG: 299675
FIXED-IN: 4.10.4
REVIEW: 110401
|
|
If an expanded folder with filtered children is collapsed or removed,
and the parent-child relationship cannot be determined by parsing the
URLs, this patch makes sure that the filtered children do not reappear
when the filter bar is cleared.
REVIEW: 109455
|
|
Conflicts:
dolphin/src/kitemviews/kfileitemmodel.cpp
|
|
This is analogous to commit e053ecdcd57cc39fdcbc314fc8dd22c8b9dbdd4f,
which fixes the same problem for the case that the parent folder is
deleted.
BUG: 316335
FIXED-IN: 4.10.2
REVIEW: 109343
|
|
changes! :)
* Fixed the "Network browser" and "timeline" issues, by using the
KDirLister's itemsAdded(KUrl,KFileItemList) signal -> Use the
given Url to define the parent-child relationship.
* Changed the name of the slot "slotNewItems" to "slotItemsAdded"
for consistency with the signal.
* Use a QHash<KFileItem, ItemData*> instead of a QSet<KFileItem> to
store the filtered data (needed to keep the O(1) lookup for filtered
KFileItems in slotItemsDeleted + needed to fix bug 311912 "After
erasing a filter, some thumbnails randomly disappear")
* Made the determination of the "expandedParentsCount" slightly
simpler - just adding 1 to the parent's level (Also needed to fix the
"Network browser" and "timeline" issues)
FIXED-IN: 4.11.0
REVIEW: 109180
BUG: 304565
BUG: 311912
BUG: 312890
BUG: 315593
|
|
Conflicts:
dolphin/src/tests/kfileitemmodeltest.cpp
lib/konq/konq_operations.cpp
|
|
Fixes the problem that filtered children of expanded deleted folders
reappear if the filter is cleared.
BUG: 315210
FIXED-IN: 4.10.1
REVIEW: 108976
|
|
The previous approach, which was based on comparing the URLs as
strings, was not only very complex, but also could lead to
inconsistencies in the model, namely, that not all children were
removed from the model when the dir lister reported the parent as
deleted. Later on, this could even lead to a crash.
BUG: 311947
FIXED-IN: 4.11
REVIEW: 108766
|
|
|
|
Conflicts:
dolphin/src/tests/kfileitemmodeltest.cpp
|
|
The regression happened in the master branch only, but I think it
doesn't hurt to add the test to the stable branch.
CCBUG: 314046
|
|
Conflicts:
dolphin/src/tests/kfileitemmodeltest.cpp
|
