| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
Currently, KStandardItemListWidgetInformant::itemSizeHint() calls the
model's data(int) method for every single item, but the full data is
actually only needed for the size calculation in Compact View. In
Details View, no data is needed at all to determine the size required
for the item, and in Icons View, only the name is needed.
This patch makes it possible for subclasses of
KStandardItemListWidgetInformant to provide an alternative way to
obtain the "text", and implements this in the subclass
KFileItemListWidgetInformant.
The final goal is to achieve that the QHash which contains all data
for a file item is only created if it is really needed, e.g., because
the view needs access to the data for displaying the item on the
screen.
REVIEW: 112253
|
|
Fixes the color of non-selected items to make them
readable with every color scheme.
BUG: 286459
FIXED-IN: 4.11.2
REVIEW: 112483
|
|
Removed all signal-slot-connections related to DolphinNewFileMenu->errorMessage(QString)
in DolphinMainWindow and DolphinContextMenu and replaced it by a better solution.
Now we make use of the already existing DolphinNewFileMenuObserver singleton class to achieve a better
error handling, because every newly created DolphinContextMenu instance registers himself by DolphinNewFileMenuObserver
and we use this to connect the errorMessage(QString) signal of every DolphinContextMenu instance to the errorMessage(QString)
signal of the DolphinNewFileMenuObserver singleton class.
So we need only one connection from DolphinNewFileMenuObserver to DolphinMainWindow (or to DolphinPart) to
collect all error messages thrown by every DolphinNewFileMenu instance.
REVIEW: 112178
|
|
|
|
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
|
|
m_sizeHintCache.fill() in KItemListSizeHintResolver::clearCache().
REVIEW: 112179
|
|
|
|
CCBUG: 314544
REVIEW: 112117
|
|
This patch changes the status bar text dolphin shows when a folder is
hovered. It now shows full folder info, eg:
"mydir (folder, symlink to /opt/mydir")
instead of:
"mydir"
This is consistent with dolphin's behavior on regular files, and
DolphinPart already does that (DolphinPart::slotRequestItemInfo has no
special cases for folders).
CCBUG: 260717
REVIEW: 112106
|
|
The purpose of this change is to give the user a chance to see hover
file information if it doesn't fit in the status bar, by allowing to
click on the file and hover on the status bar.
As it's now possible to have status bar texts starting with "<qt>",
DolphinPart::updateStatusBar() must escape strings. Otherwise,
filenames such as "<qt>Tes<font color=red>t" would be rendered as HTML
data in konqueror's status bar when selected.
BUG: 260717
FIXED-IN: 4.12.0
REVIEW: 111934
|
|
handling is now done via signals.
REVIEW: 111989
|
|
|
|
|
|
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 fixes the same issue as 4450f8449af91e491636728a4669e2a9e27b49fa,
but for the status bar's tooltip text.
BUG: 323170
FIXED-IN: 4.11.0
REVIEW: 111836
|
|
Unlike escape, convertFromPlainText preserves whitespace sequences
CCBUG: 321778
REVIEW: 111835
|
|
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
|
|
The function assumes implicitly that the moved range always starts with
the index 0. This is indeed the case at the moment, but it might make
sense to change that in the future. This commit prevents that we get an
out of range problem then.
Thanks to Emmanuel Pescosta for finding this problem, see
https://git.reviewboard.kde.org/r/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.
|
|
|
|
BUG: 321577
FIXED-IN: 4.12.0
REVIEW: 111805
|
|
This feature might have been useful in some cases, but it's most likely
not useful enough to justify that we accept the bugs that it causes.
Even though some of these bugs are not Dolphin's fault at all, they
cause serious problems for users in some cases.
I'm pushing this commit to master only because I prefer to not push such
behavior changes to 4.11 at this point of the release cycle.
BUG: 288629
CCBUG: 322299
CCBUG: 322812
FIXED-IN: 4.12.0
REVIEW: 111692
|
|
|
|
Thanks to Emmanuel for pointing out a problem with my first patch.
BUG: 322965
FIXED-IN: 4.11.0
REVIEW: 111722
|
|
So that filenames that look like HTML don't get fancy-formatted when
we show info about them (i.e. on hover)
This patch fixes the same issue in two places:
- dolphin, by setting Qt::PlainText on the status bar's label
- konqueror, by escaping setStatusBarText strings emitted by
DolphinPart
BUG: 321778
FIXED-IN: 4.11.0
REVIEW: 111746
|
|
This small change saves a lot of CPU cycles when the items are resorted.
REVIEW: 111700
|
|
open these urls in the default browser instead.
BUG: 283475
BUG: 318217
FIXED-IN: 4.11.0
REVIEW: 111674
|
|
|
|
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
|
|
|
|
|
|
The problem was that DolphinItemListView overrides the virtual function
onItemLayoutChanged() without calling the base class implementation.
Therefore, KStandardItemListView::updateLayoutOfVisibleItems(), which
calls initializeItemListWidget(), is never called.
This patch refactors the "change item layout"/"supports item expanding"
code a bit to make it more robust and fix the problem that the view
looks "messed up" when switching from Details View without expandable
folders to Icons View.
I'm only pushing this patch to master (going to be KDE 4.12).
The patch is a bit too intrusive for the KDE/4.11 branch for my taste
at this point of the release cycle, and the bug is not a real
showstopper. If it works well in master, one could consider backporting
it to a 4.11.x bug fix release.
Thanks to Emmanuel Pescosta for helping to analyze this issue.
BUG: 302703
REVIEW: 111632
FIXED-IN: 4.12.0
|
|
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.
|
