| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 272aa65bb55dd31f58e8a8e24ea7bc8bd2712daa.
|
|
This reverts commit 63e12c0cdf4e3437b95b9c50e5791dbf97183687.
|
|
|
|
This reverts commit 996e430b62075c5b69571f141456dbe5f2956679.
The accompanying feature to make the behavior configurable and disable
it by default was reverted in 21.08, so we need to revert the feature
itself as well and only ship it in 21.12, to avoid changing people's
setting back and forth, which is often not well-received.
|
|
This reverts commit fd2203bb3925edb5d657d49a706e26ea736362d2.
|
|
|
|
|
|
Since KIO 5.82, KCoreDirLister (the base class of KDirLister) emits a jobError()
signal when the ListJob used internally emits an error.
Drop KFileItemModelDirLister class, now redundant.
This also bump the KF version to 5.82.
|
|
Hidden files and folders are always displayed after
not hidden files.
BUG: 241227
Revision: https://phabricator.kde.org/D29115
|
|
|
|
|
|
Unfortunately licensedigger does not strip the trailing * characters.
While at it, use a common style for all source files.
|
|
|
|
GIT_SILENT
|
|
|
|
We already depend on KF5 > 5.47, so we are ready to switch to the
non-deprecated fastInsert() method.
|
|
Summary:
With the new uds implementation, when some data is meant to replace an old one, it has to use replace() instead of insert() to avoid an assert of data already exists.
Use 3 different entries and only insert().
Test Plan:
before: crash in the uds assert
after: passes the test
Reviewers: #dolphin, #frameworks, elvisangelaccio
Reviewed By: #dolphin, elvisangelaccio
Subscribers: bcooksley, bshah, nalvarez, cfeck, dfaure, aacid, ngraham, bruns, elvisangelaccio, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D13813
|
|
Summary: This reverts commit 2104d18a6760d28d24665a3281ef090c198c44e7.
Test Plan: revert-hammer
Reviewers:
Subscribers:
|
|
Summary:
With the new uds implementation, when some data is meant to replace an old one, it has to use replace() instead of insert() to avoid an assert of data already exists.
Use 3 different entries and only insert().
Test Plan:
before: crash in the uds assert
after: passes the test
Reviewers: #dolphin, #frameworks, elvisangelaccio
Reviewed By: #dolphin, elvisangelaccio
Subscribers: dfaure, aacid, ngraham, bruns, elvisangelaccio, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D13813
|
|
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
|
