The capacity bars will no longer update when capacity changes. It only
checks the size on init.
Updating during polish event is only a temporarily solution just to
draft code flow for seperating logic from painting. Eventually this
logic update should be in a worker thread detached from blocking the
rendering thread that blocks launching the dolphin window.
Draws overtop text that's goes below the baseline like a 'j'. It's
fairly difficult to add extra space below the text as the places view
is a "details" view, so the text is vertically centered in the
widget's "row" as you'd desire it to in the main file view.
We can make the widget 8px taller, adding 4px above and below so
there's adequate room for the capacitybar, but that wastes 4px for
each mount point.
Ideally we'd use the "compact" view, which displays the text/size in a
column beside the icon. However the compact view was not designed to
take up the entire width of the viewport. It's also designed to
overflow with a horizontal scrollbar.
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
In KDirectoryContentsCounterWorker::CountResult, the first parameter in
the call of walkDir was wrong. It should be path without conversion,
because the conversion is done in the called function.
BUG: 428282
When session restore is populating the main window, it's unconditional;
you'll get whatever was there before. This can be a problem if any of
those things are now missing. For example, maybe you were browsing files
on a removable disk, then quit Dolphin, and finally removed the disk. The
next time you launch Dolphin again, it will try to show you the
view from the now-missing removable disk.
To prevent this, we now look at all the URLs in all of the view
containers that were created after session-restore has finished doing
its thing; if any of them are invalid local URLs, we change the URL to
the home folder instead to avoid showing the user a view with an invalid
location in it.
BUG: 427619
FIXED-IN: 20.12
Right now, when you unmount a device that any active view containers are
displaying, nothing in the view changes. As a result, it's possible to
try to navigate to files or folders in that view, which cannot be done
because the disk that the files or folders are located on has been
unmounted!
With this commit, we detect that case and switch the view containers
to show the home folder after the disk whose contents they are displaying
gets unmounted.
BUG: 158934
FIXED-IN: 20.12
The function was previously assuming that each tab view has exactly one
view container, which is not necessarily accurate; some could have a
split view open.
It will be removed in Qt 6 without porting strategy:
f43cb31ba0
We know that that variants will be either ints (for `count`) or longs (for `size`),
so just convert them to longs (to avoid overflows) and compare those.
Quoting from:
714409b23c
```
The QLabel changes to the pixmap/picture getters provide the following
migration path:
QPixmap *ppix = l->pixmap(); // up to 5.15, warns in 5.15
QPixmap pval = l->pixmap(Qt::ReturnByValue); // new in 5.15, works in 6
QPixmap pixmap = l->pixmap(); // from Qt 6 on
```
Since we can't require 5.15 yet in dolphin, the port is done only when
building with Qt >= 5.15
The QSet range constructor requires Qt 5.14.
In `DolphinView::slotHeaderContextMenuRequested()` the conversion from
QList to QSet was pointless, so we just use a QList now.
Before, when Dolphin was closed but opened with any URLs, it would open
a new window with only those URLs, rather than restoring any window
state (if the user has this feature enabled).
Now, Dolphin will first restore state (if enabled) and then append any
URLs, rather than replacing the existing set of URLs.
The "new instance" case was previously handled automatically and now
needs to be explictly handled by checking for it, to make sure that new
instances give you a clean window rather than a state-restored window.
BUG: 427274
FIXED-IN: 20.12
Right now the back/foward mouse buttons work, but also if you hold either
of them and move the mouse the rubberband selection is triggered.
This is the correct fix (instead of commit d0c71a1435), to match the
original code before the touch events patches, we need to check the
back/foward buttons after mouseButtonPressed is emitted and before
triggering the rubberbad selection.
