| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
REVIEW: 119428
|
|
|
|
In the Places Panel, there is always exactly one selected item, which is
equal to the current item. Since the selected item is highlighted by
drawing its background in a different color, it is not really necessary
to highlight additionally that it is the current item.
This is achieved by removing the calls to
KItemListWidget::setCurrent(true) from KItemListView. The "current"
information in the widget is only used for deciding if the "current item
highlighting", like an underline in Oxygen, should be drawn.
The motivation for this change is that I have seem some complaints about
the "current item" highlighting, which can be even more distracting with
non-Oxygen styles.
REVIEW: 119019
|
|
|
|
|
|
By separating the width and height info, we can save some unnecessary
overhead in terms of memory and CPU cycles, and make the calculation of
the height of a row (or the width of a column in Compact View) a bit
simpler.
To achieve this, this patch extends the concept of "logical rows"
(which are actually columns in Compact View) to "logical width" and
"logical height" (which is the actual height and width, respectively, in
Compact View). The distinction between rows/columns and "logical"
rows/columns may be a bit confusing, but the confusion is already in the
current code, and I hope that it will be mitigated a bit by prefixing
the corresponding variables with "logical".
REVIEW: 118454
|
|
Conflicts:
lib/konq/konq_operations.cpp
|
|
opening/refreshing contents of Dolphin
Take the scrollbar spacing into account.
BUG: 334696
REVIEW: 118319
FIXED-IN: 4.13.2
|
|
Since the master branch had never been merged into frameworks since the
creation of the frameworks branch, I had to fix a couple of merge
conflicts and make another change in order to make it build - I hope I
did not get anything wrong.
We should probably merge master into frameworks on a regular basis from
now on.
CCMAIL:[email protected]
Conflicts:
dolphin/src/dolphinmainwindow.cpp
dolphin/src/search/dolphinfacetswidget.cpp
dolphin/src/statusbar/dolphinstatusbar.cpp
dolphin/src/views/dolphinview.cpp
|
|
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.
|
|
|
|
This does not work properly yet, there are probably quite a few bad signal/
slot connections due to KUrl -> QUrl. However dolphin starts without
crashing.
Accessibility is not ported since that changed quite a lot from Qt4 -> Qt5
and I have no idea how it is supposed to be used.
This is the first commit for review 117395
|
|
If the user sets a maximum number of text lines in the settings, this
number was translated into a maximum height in pixels using
QFontMetrics::lineSpacing() before this commit.
In KStandardItemListWidgetInformant::itemSizeHint(), this maximum height
limited the size that is reserved for the item.
However, in KStandardItemListWidget::updateIconsLayoutTextCache(), the
maximum height was translated back into a maximum number of lines,
which limits the number of lines that are created using the QTextLayout.
This approach could lead to problems if the real height of the layouted
text is 1 pixel more or less than QFontMetrics::lineSpacing() times
"number of lines".
Now we do not store a "maximum height" inside the "maximum size"
explicitly, but store a maximum number of lines and a maximum with (for
Compact View) separately, and then use the number of lines also to
calculate the required size in
KStandardItemListWidgetInformant::itemSizeHint(). This should make sure
that the correct height is reserved for each item.
Thanks to Christoph Feck and Emmanuel Pescosta for helping to debug this
problem and testing the patch.
BUG: 323841
FIXED-IN: 4.13
REVIEW: 113871
|
|
Also update the font of the meta data widget in InformationPanelContent (smallest readable font).
BUG: 329186
BUG: 315061
FIXED-IN: 4.13
REVIEW: 115958
|
|
KItemListViewLayouter uses a KItemListSizeHintResolver to find out how
much space the items will need in the view.
Before this commit, the size hint resolver object could be changed at
runtime, and it could also be null. However, we never made use of these
possibilities, so all the code that checks if m_sizeHintResolver is
null is actually not needed at all.
|
|
The speed up is really small, but theses changes are mostly straightforward and make the code a bit nicer - break
the KStandardItemListWidgetInformant::itemSizeHint beast into three smaller functions.
FIXED-IN: 4.13
REVIEW: 112979
|
|
Since Dolphin 2.0, we have stored the selected items in a QSet<int>,
which is neither space-efficient nor particularly fast when inserting
many items which are in a consecutive range.
This commit replaces the QSet<int> by a new class "KItemSet", which
stores the items in a sorted list of ranges. For each range, we only
store the first index and the length of the range, so we need a lot
less memory for most common selection patterns, and we also save quite
a few CPU cycles in many situations, because adding an item to the
KItemSet will in many cases not need a memory allocation at all, and
it's particularly easy when inserting sorted items into the KItemSet in
a row.
KItemSet contains a minimal subset of QSet's API which makes it
suitable as a drop-in replacement for our needs. It also has iterators,
such that the items can be iterated through easily, also with foreach.
One advantage of KItemSet compared to QSet<int> is that the items are
always iterated through in ascending order.
REVIEW: 113488
|
|
|
|
Take the style option vertical/horizontal margin into account
for the calculation of the new scroll offset.
Thanks to Frank for pointing out two other problems with "Page Up/Down" and providing
a better way to fix these problems. :)
BUG: 311099
FIXED-IN: 4.11.2
REVIEW: 112678
|
|
|
|
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
|
|
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
|
|
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
|
|
If many item ranges are removed, KItemListView::slotItemsRemoved()
could take very long because it looped over all items after the first
removed one for every removed range, even if most of these items are
not visible at all.
This commit improves this by just looping over the visible items (whose
number is limited by the window size) for each range.
Test case (for very large N):
touch {1..N}.png
touch {1..N}.jpg
(wait until all files are shown in the view)
rm *.jpg
REVIEW: 111398
|
|
It's quite expensive to re-calculate them, so we should better just move
them to the correct position, rather than throwing them away.
REVIEW: 111399
|
|
This was the root cause of bug 317827. The assert tried to make sure
that we never access KItemListSizeHintResolver from
KItemListViewLayouter inside the loop over the item ranges. This would
be dangerous because it might be in an inconsistent state - the removed
item ranges were removed step by step, so accessing the item size hints
before the operation was finished could lead to wrong results.
The solution is to insert/remove all item ranges immediately. A nice
side effect is that there are no sources of O(N^2) complexity in
KItemListSizeHintResolver any more if many item ranges are
inserted/removed.
BUG: 317827
FIXED-IN: 4.11.0
REVIEW: 111382
|
|
REVIEW: 110505
|
|
When doing a drop, a check is performed to see if it is within x pixels
from the top or x pixel from the bottom of the rect. If it is, then the
drop is considered a drop between items.
This x was fixed to qMax( 4, myStyleOption.padding ) which would
generally be 4. This is fine for some cases, but when the rectangle size
increases then this 4 pixels is not enough. Hence this 'x' is now being
set to 30% of the rectangle height.
By default the rectangle height is 20 pixels, so x is now 6 instead of 4
in the default case, which does make it slightly easier.
Also, this in-between-items check is only performed when moving from one
item to another. This is not good since if you enter the item and the
bottom, the indicator is shown, and then as to start moving it up it
stops showing, and then it should start showing again as you approach
the top edge.
Modified the code to run the check on every mouse drag event even if the
hovered item has not changed.
Both these changes combined make it much easier to drag and drop items.
REVIEW: 110342
|
|
I'm not sure yet if there is a problem somewhere else in the code. For
the time being, I think it's better to replace the assert by a TODO
comment to prevent that users find out the hard way that there is
something that we're not quite sure about.
BUG: 317827
FIXED-IN: 4.10.3
|
|
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
|
|
The height of the header widget must be subtracted from the view's
height in Details View to determine the "pageStep" for the scroll bar.
BUG: 315619
FIXED-IN: 4.10.2
REVIEW: 109210
|
|
|
|
panel
BUG: 309338
FIXED-IN: 4.9.3
REVIEW: 107070
|
|
|
|
|
|
in Konqueror. The original fix, commit 4f7ed2b, prevents drag and drop from
working correctly.
CCBUG: 302329
REVIEW: 106569
|
|
|
|
Konqueror.
BUG: 302329
FIXED-IN: 4.9.2
REVIEW: 106569
|
|
CCMAIL: [email protected]
CCMAIL: [email protected]
|
|
REVIEW : 106555
|
|
|
|
|
|
|
|
|
|
|
|
|
