| Age | Commit message (Collapse) | Author |
|
This all seems to be done by the PreviewJob in KIO already.
|
|
The preview job does an async stat on the file, so we might as well
use its information to determine the icon.
Also only determine mime type in the final "ResolveAll" step since
it will initially resolve roles but mime type isn't necessarily fast.
|
|
|
|
Folder count would not update properly when user would delete file from
a folder, or add a new file to it.
Previously when size value is set to -2 after update, the update will
never be called again unless user presses F5. This change will instead
reset that -2 to 0 whenever we are requesting for calculating
directory sizes.
We never updated the count when a file was deleted, so that has been added as well.
This change also calculates the item counts from the processedAmount, which is the total amount of items we're processing. From there we remove the unwanted items and get the final count.
For remote files, we set the count to -1 since we don't calculate them.
BUG: 500502
|
|
Now all overlays icons in kitemviews are added in
KStandardItemListWidget::updatePixmapCache.
data[iconOverlays] now contains icon names.
DolphinFileItemListWidget::refreshCache is the sole responsible of
setting the overlays either coming from KFileItemModelRolesUpdater or
KVersionControlPlugin.
This garantees consistency in rendering.
BUG: 497372
|
|
|
|
|
|
If filename of an item was updated previously, it would modify the model
before the file was actually changed. This led to the model calling
a signal that would try to run a previewjob, but since the filename
is not actually changed yet on disk, it would fail.
This patch moves the model updating after copyjob. Copyjob
will take care of the file renaming if there is already existing file.
We just need to update the model correctly after the job has succeeded.
BUG:497555
|
|
|
|
improve stopping, improve data caching
Two user visible changes:
* we can see the dir size changing as it is updated.
* This makes the file counting a lot more reactive, when changing directories for instance.
`KDirectoryContentsCounterWorker::walkDir` is not recursive anymore.
The cache is now shared and only a single thread is used to count size recursively.
|
|
Two changes:
* Prioritise size counting for visible path
* stop the worker when switching dirs
|
|
|
|
|
|
|
|
|
|
This way we get a build time warning if the var isn't defined at all, e.g.
a missing check_include_files() CMake call.
|
|
|
|
This shows a slideshow of thumbs when the user hovers a file item.
|
|
|
|
KFileItemListView contents are periodically scanned by KFileItemModelRolesUpdater.
It uses then KDirectoryContentsCounter to scan directories to determine their size possibly recursively.
Introduce a scanDirectories setting to disable directory scanning by KFileItemModelRolesUpdater.
BUG: 426617
FIXED-IN: 20.08.3
|
|
|
|
|
|
Unfortunately licensedigger does not strip the trailing * characters.
While at it, use a common style for all source files.
|
|
Summary:
FileWidgets read from kdeglobals the property "MaximumSize" under "PreviewSettings" to decide if a preview will be generated for that file.
There is no current GUI to change that file size limit. On the other hand Dolphin ignores it.
This patch aims to fix that by adding new configuration options to Dolphin. That is a new spinbox in Dolphin settings under General -> Previews tab.
Test Plan:
1 - Set up a local folder with 2 jpg images of less and more than 1 MB respectively.
2 - Go to Dolphin Preferences. General -> Previews and check "JPEG Images" from
the list. And set "Skip previews for files above:" to 1MB.
3 - Navigate to the afore mentioned folder. Only the image of size less than 1 MB should
show a preview.
BUG: 331240
Reviewers: ngraham, #dolphin, meven, elvisangelaccio
Reviewed By: ngraham, #dolphin, meven, elvisangelaccio
Subscribers: cfeck, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D28402
|
|
Summary:
Allow to compute the recursive size of directories to fill the details view size column.
A setting allow to set a limit to the recursive level, allowing the user to have some power over the setting.
When sorting by size and the feature is on, we get progressive ordering as the directory size are gathered.
KDirectoryContentsCounter uses a cache internally to keep results so that it can display directory size faster, but counts the dir size of directories each time it is asked to count the size a directory nevertheless and when the size has changed, it is updated.
KDirectoryContentsCounter uses one worker per instance only, meaning one process per view makes the disk spin.
FIXED-IN: 20.08
BUG: 190580
BUG: 158090
Test Plan:
With some recursion allowed:
{F8267580}
Without any recursion allowed (default):
{F8267581}
Reviewers: elvisangelaccio, ngraham, #dolphin
Reviewed By: elvisangelaccio, ngraham, #dolphin
Subscribers: feverfew, anthonyfieroni, iasensio, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D25335
|
|
|
|
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
|
|
|
|
Also use override instead of Q_DECL_OVERRIDE
|
|
|
|
REVIEW: 125675
|
|
REVIEW: 125584
|
|
the deprecated KVersionControlPlugin interface from konqlib
REVIEW: 122687
|
|
REVIEW: 121078
|
|
|
|
REVIEW: 120582
|
|
This conversion was performed automatically using convert2qt5signalslot.
The only manual changes required were changing the overloaded signal
KDirLister::redirection and KDirLister::completed from KUrl to QUrl. All
other cases were no problem since these signals are not overloaded and a
static_cast for disambiguation is not necessary.
Code inside HAVE_BALOO is not converted yet, will do that once I can build
a version with Baloo.
|
|
Nepomuk is being replaced with Baloo
|
|
KFileItemModel allows to find out the index of a KFileItem with its
index(const KFileItem&) method. Calling this method is not extremely
expensive, but it's also not free (it looks up the URL of the KFileItem
in a QHash, i.e., it has to call qHash(QString) for the full URL).
In KFileItemModelRolesUpdater, we sometimes converted the known index to
a KFileItem and then back to an index in applyResolvedRoles(KFileItem).
This patch fixes this by modifying applyResolvedRoles such that it takes
the index directly as its argument.
REVIEW: 114847
|
|
This prevents that the GUI freezes if there are many files inside the
directory, or if the access to the directory is slow for some other
reason.
BUG: 318518
REVIEW: 111920
FIXED-IN: 4.12.0
|
|
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 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
|
|
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
|
|
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
|
|
I saw a runtime warning from QMetaObject::invokeMethod() that KJob* is
not a registered type. Since we don't use that argument in
slotPreviewJobFinished(KJob*) anyway, it's best to remove it.
|
|
The main change in this commit is that we do not determine expensive
roles (like previews, mime types, etc) for all items, but only for the
visible ones and those close to the visible area or on the first and
the last page of the view.
This prevents that the CPU and hard drive are kept busy for quite some
time after entering a folder while all items are handled asynchronously.
There is one known problem at the moment: when sorting by "Type" or
another role that can be resolved by KFileItemModelRolesUpdater, the
icons of the visible items are sometimes not loaded while the sorting is
still in progress. I will try to fix this issue during the next few
days.
REVIEW: 110839
|
|
When entering a folder, KFileItemModelRolesUpdater has not yet been
informed about the visible index range by the view when it tries to
determine icons synchronously. This resulted in the problem that it
tried to determine icons for all items in random order, and some visible
icons were somtimes still unknown after the "synchronous icon loading"
timeout of 200 ms.
This commit tries to improve the situation by loading icons starting
with the first item in increasing order. This should make it less likely
that some visible items still have unknown icons after 200 ms.
BUG: 316129
FIXED-IN: 4.10.3
REVIEW: 109843
|
|
guide on techbase - http://techbase.kde.org/Projects/Nepomuk/Nepomuk2Port
REVIEW: 106825
|