| Age | Commit message (Collapse) | Author |
|
|
|
1. The anchorChanged() signal is not needed.
2. The only place where setAnchorItem() is called is in
beginAnchoredSelection() -> merge both functions.
|
|
Thanks to Tirtha Chatterjee for the patch!
REVIEW: 102435
|
|
If e.g. the down-arrow-key is pressed constantly the view does not
scroll as the animation always will get restarted. Assure that
the animation proceeds in this case.
|
|
The smooth-scrolling may only get turned off after finishing the
animation, if the scrollbar is not currently modified by the user.
|
|
Don't change the selection if the anchor is invalid. This fixes
the issue that items might get selected during changing a directory.
|
|
- Don't clear the selection on mouse-press events, do it (if
allowed) in the mouse-release-event. Otherwise dragging of
multiple selected items would not be possible.
- Don't clear the selection when the context-menu gets opened
by a right-click.
- Fix issue that dragging is not possible after the first
drop that has been canceled.
|
|
Use the same approach like in KDirModel::mimeData().
|
|
|
|
Includes a lot of TODOs but is a base for getting back full drag
and drop support quite soon.
|
|
The old selection must be remembered before starting the rubberband
selection, otherwise it would not be possible anymore to deselect
items that have been selected by the rubberband itself.
|
|
If the user has pressed the Shift- or Control-key during the
rubberband selection, the previous selection should not be cleared.
|
|
In this case the rubberband automatically uses the whole width of
the view.
|
|
|
|
The autoscrolling should not be triggered if the rubberband
direction is different from the autoscroll direction
|
|
If the autoscrolling has been activated when using the rubberband,
it was possible that an endless recursion occured as the
autoscrolling triggered a change of the rubberband which triggered
a change of the autoscrolling etc.
|
|
This is just a rough draft: The rubberband gets visible and an
automatic scrolling is done if the autoscroll-margins have been
reached. However currently no items get selected yet. Currently
the autoscrolling has a severe bug if the scrollbars are manually
changed before or after a rubberband selection.
|
|
|
|
Before this commit, expanding and collapsing folders in the details
view would lead to strange results in a folder with the items "a",
"a/a/", "a/a/1", "a/a-1/", and "a/a-1/1". The problem was that the
comparison between "a/a/1" and "a/a-1/1" went wrong: the first
character in which the paths differ is a "/" in one of the items, such
that the code that reduces this 'index' in
KFileItemModel::expansionLevelsCompare in order to find the 'common
path' did nothing because it checked that only *one* of the two items
does not have an "/" at the position 'index'.
|
|
They could lead to crashes if the Details View is used and the
view is not wide enough to show all columns for the items.
|
|
|
|
|
|
As the textbounding-rectangle is now a property of KItemListWidget
also the default visual appearance is moved now from
KFileItemListWidget to KItemListWidget.
|
|
It has been split now to iconBoundingRect() and textBoundingRect().
This is required to implement the rubberband in an efficient way
and makes it more explicit what rectangle is returned.
|
|
1. Implement DolphinView::clearSelection().
2. Simplify DolphinView::invertSelection().
I found, fixed, and unit-tested a bug in the selection
manager which was uncovered by this change.
|
|
Things that are still missing:
1. Moving to the previous/next row with Up/Down in Icons View,
moving to the previous/next columns in Compact View.
2. Navigation in Details View.
Note that scrolling to the current item doesn't work yet, and
that the view does not have keyboard focus initially, so one has
to click the view before keyboard navigation and seleciton works.
|
|
Up to now, KItemListContainer would show both a vertical and
horizontal scroll bar after a view mode change. This commit
fixes that by setting the maximum and the value of the scroll
bar that is not needed to 0 in
KItemListContainer::updateScrollBars().
|
|
|
|
|
|
This commit adds a unit test that changes the selection in various
ways, verifies the result and checks that the selection manager's
selectionChanged signal has been emitted correctly. The test is
data-driven, so I hope that most further testing needs can be
fulfilled by adding new test data.
Moreover, I changed selectedItems() such that the anchored
selection is only taken into account if anchor and current item
are different. The reason is that in some situation the anchor
should not be selected initially (i.e., if an already selected
item is Control-clicked). If the anchor should be selected from
the beginning, it must be selected manually.
|
|
This commit makes sure that the signal is emitted with the correct
current and previous selection after a selection change, and
that the signal is emitted exactly once in
KItemListSelectionManager::itemsInserted and
KItemListSelectionManager::itemsRemoved.
|
|
Unit test included.
|
|
Key press events are forwarded from KItemListContainer to
KItemListController. Right now, only the 'Home' and 'End' keys
are handled (arrow keys require some more work because their action
depends on the view mode).
Note:
1. Before key presses are handled, the view has to be clicked with
the mouse. It seems that the view does not have the keyboard
focus initially.
2. The view does not scroll to the new current item yet.
|
|
In Dolphin, we don't actually use the 'Deselect' and 'Toggle'
modes for anchored selections, so we can just remove these
modes and always use 'Select' to reduce code complexity.
|
|
|
|
If items are added or removed in the model, not only the
current item, but also the anchor item, which is the
starting point for any selections via Shift+Click or
Shift+Key, needs to be updated.
BUG: 262638
FIXED-IN: 4.8.0
|
|
|
|
It still looks a bit ugly, but at least we can see the current
item now :-) It is only updated by mouse clicks at the moment.
|
|
|
|
|
|
|
|
The overall time for creating previews is faster the more items
are passed to KIO::previewJob() in parallel instead of passing
e.g. only 100 items once and start several KIO::previewJobs
sequentially.
However in the worst case KIO::previewJob() might
block the application for several seconds if the
MIME-type of the passed KFileItems are unknown and e.g. 10000 items
are forwarded.
So KFileItemModelRolesUpdater will now take care to resolve as many
MIME-types as possible until a timeout is reached and will only pass
those items to KIO::previewJob().
For huge image folders, where the MIME-type can be determined very
fast, this means that the overall time for creating previews will
decrease without blocking the application. For "worst case" directories
where resolving the MIME-type can get very expensive this approach
assures no blocking of the user-interface although the overall time
until all previews are generated might slightly increase.
|
|
An item should only be triggered after a mouse release
event if the mouse press has been done at the same position.
|
|
|
|
Dolphin 2.0 will get a new view-engine with the
following improvements:
- Better performance
- Animated transitions
- No clipped filenames due to dynamic item-sizes
- Grouping support for all view-modes
- Non-rectangular selection areas
- Simplified code for better maintenance
More details will be provided in a blog-entry during
the next days.
Please note that the code is in a very
early alpha-stage and although the most tricky parts
have been implemented already very basic things like
drag and drop or selections have not been pushed yet.
Those things are rather trivial to implement but this
still will take some time.
|