| Age | Commit message (Collapse) | Author |
|---|
|
One scroll with the mouse wheel is supposed to scroll the view by
QApplication::wheelScrollLines, however previous to this commit Dolphin
scrolled the view by QApplication::wheelScrollLines^2 instead, which
was wrong and way too much.
This commit fixes this by defining one line height as the height of the
current default font. This value is multiplied by
QApplication::wheelScrollLines to determine the scroll amount per mouse
wheel scroll.
In details view mode however, where there really are rows to go by,
this commit makes sure to always scroll by full rows. The number of
rows to scroll is determined by rounding up from the scroll amount used
in the other view modes.
Co-authored-by: Felix Ernst
|
|
The screen reader Orca has seen some fundamental changes between
Orca 46 and Orca 47. While they are improvements overall, they do
require changes to Dolphin to preserve the intended user
experience for Orca users.
The biggest change is perhaps that Orca will now not only announce
changes to the currently focused item, but also of its parent,
which means we do not need to pass focus around between file items
and the main view within Dolphin, but can keep focus on the file
items most of the time. This commit implements this.
The only exception of when we cannot have focus on the items within
the main view is when the current location is empty or not loaded
yet. Only then is the focus moved to the view itself and the
placeholderMessage is announced.
This commit worsens the UX for users of Orca 46 or older, so this
should only be merged once most users are on Orca 47 or later.
|
|
**Open Path**
When user clicks on "Open Path" after searching for an item,
user expects the view to show the item immediately.
We wait for the KItemListSmoothScroller to be done with its animation before the
scrollbar sizes are being changed.
**Open Path in New Tab**
When user selects "Open Path in New Tab", we open a new tab to the folder where the file is, then select and set the file current. We need to get the correct tab when opening one, so it has been added as a return value.
BUG:495613
|
|
This commit brings the main view of Dolphin into a usable state
accessibility-wise. Users of screen readers should have a way better
experience while browsing files and folders and navigating along the
file system hierarchy.
This commit fixes most of the remaining already-identified
accessibility issues listed in
https://invent.kde.org/teams/accessibility/collaboration/-/issues/28,
but not all. Namely, these should now be fixed:
1. Orca should read the element type in dolphin (file, folder, device,
link to folder, link to file)
2. Orca should read complete label in icon and compact view mode,
currently it only speaks the name, but there could be additional
information like the number of elements or the file size.
3. Orca is not able to announce Selecting / Unselecting files in
Dolphin. It also never announces how many items are selected in total.
(Announcing the total selection can be done by reading out the view
element or by pressing the Tab key to get to the status bar with the
relevant information.)
4. Dolphin opens on the home directory, but Orca doesn't tell you so.
Consider enclosing the area in a frame/panel which updates its
accessible name each time you modify the current path by entering or
leaving a directory.
5. I don't know what the folder presentation widget is, but it should
be presented as a grid view. Currently, we have a terrible experience
because the entire row of folders is read at once, with no indication
that we can move left and right with the arrows to go between the
elements of a row. When I found that out, however, I discovered that
when you're on the last icon of the first row and press right arrow,
you get to the first icon of the next row, but that's not announced,
instead, the whole row is announced at once
6. Orca should announce the current elements instead of "layered pane"
when the Folder / File view gets the focus in dolphin
7. Orca reads only name in Table View only of Dolphin
8. Items are sometimes confusingly announced as "collapsed" in contexts
in which there is no concept of collapsing/expanding e.g. in icon view
mode.
A lot of code was moved around and renamed. The three accessibility
classes, which all used to be in the same file, are moved into separate
files.
*Acknowledgement*
Thanks to Christian Hempfling and bgt lover for testing as well as
originally identifying a lot of the pain points being addressed here.
This work is part of a my project funded through the NGI0 Entrust Fund,
a fund established by NLnet with financial support from the European
Commission's Next Generation Internet programme, under the aegis of DG
Communications Networks, Content and Technology.
https://kde.org/announcements/2024_ngi_openletter/
|
|
This MR fixes some issues related to RTL scripts:
- wrong layout in Compact View mode
- broken horizontal scrolling in Icon View and Details View modes
- broken navigation with left and right arrow keys in Details View mode
BUG: 484012
BUG: 449493
|
|
Before this commit, Dolphin's main view would not react to any
context menu events. It only showed context menus based on
hard-coded mouse or keyboard events i.e. mouse right-click and
presses of the "Menu" key.
This commit removes those hard-coded reactions and instead makes it
so the view shows a context menu whenever a QContextMenuEvent is
received. Therefore, a context menu will now be opened when any
platform- or system-specific context menu triggers are invoked e.g.
the Shift+F10 keyboard shortcut.
Aside from this, the only side-effect is a partial removal of an
unrelated bug: Previously, the hover highlight on items was never
cleared when the header column in details view mode was hovered.
With this commit, the hover is now correctly cleared most of the
time.
|
|
selected widget on focus change
|
|
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
|
|
|
|
To rename previous file:
Up or Shift-Tab
To rename next file:
Down or Tab
Credit goes to msciubidlo
FEATURE: 403931
FEATURE: 269987
BUG: 334533
FIXED-IN: 21.08
|
|
BUG: 430532
a scroll that includes an horizontal component != 0 might still be a vertical scroll
|
|
With this patch dolphin now supports the following touch gestures:
* Tap gesture to interact/open with directories, files and so on
* TapAndHold and release gesture for access to the context menu (main window, panel folder, places and information)
* TapAndHold and moving gesture for drag and drop action (main windows, panel folder and places)
* pinch gesture for zoom in main window
* kinetic scrolling (QScroller) for main window, panel folder, panel places, panel information, setting preview and service
* two fingers swipe gesture to left, right and up as shortcut to navigate back, forward and up
* two finger tap gesture to toggle item selection, similar to Ctrl and left mouse click
FEATURE: 385066
FIXED-IN: 20.11.80
You are currently rebasing branch 'touch' on '85241a924'.
|
|
Unfortunately licensedigger does not strip the trailing * characters.
While at it, use a common style for all source files.
|
|
We are supposed to use QWheelEvent::angleDelta() instead. Upon an
horizontal/vertical scroll event, its `x()`/`y()` method will return a
value different from zero.
|
|
|
|
Summary:
Dolphin currently scrolls by the height of three items at a time per "step" when
using a scroll wheel. Because item height is highly variable, this leads to scroll
speed being inconsistent between views, and generally far too fast when using
icon view with icons larger than 22px size.
This patch makes the size of the scroll step based on the text label rather than the
icon size just like D25683, ensuring that the scroll speed does not vary and become
super fast when using large icons in particular.
It also reverts 90beb4a5e37b887caad1e767046a42dad0af1ab3, which is no longer needed.
BUG: 386379
FIXED-IN: 19.12.1
Test Plan:
Use a mouse with a scroll wheel and scroll in Dolphin item views with list view,
details view, icon view, etc, using different item sizes. Speed should be
consistent in all views now, and also feel consistent with other KDE apps.
Also try with multiple scale factors to make sure the behavior does not change.
No change with high-resolution two-finger touchpad scrolling.
Reviewers: #dolphin, elvisangelaccio
Reviewed By: #dolphin, elvisangelaccio
Subscribers: ahiemstra, lots0logs, anthonyfieroni, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D19190
|
|
|
|
GIT_SILENT
|
|
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
|
|
Summary: I used CLion inspection to hunt all unused #include
Reviewers: #dolphin, elvisangelaccio, markg
Reviewed By: #dolphin, elvisangelaccio, markg
Subscribers: markg, elvisangelaccio, #dolphin
Differential Revision: https://phabricator.kde.org/D10985
|
|
Summary:
CCBUG: 386379
after recent highdpi patches on scrolling that delegated it
completely to the scrollbar, based upon the scrollbar singleStep
setted to the tallest of the items in the view.
tough this makes scrolling way too fast, and on folders where just
few filenames are longer than most we can get a single scrolling
step almost double the number of lines configured in the
mouse kcm.
Using the shortest item instead of the tallest mitigates this problem
making it a bit more usable
Test Plan:
tested on different folders in different view modes both with
mouse and touchpad
Reviewers: #dolphin, broulik, ngraham
Reviewed By: #dolphin, ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10102
|
|
|
|
Also use override instead of Q_DECL_OVERRIDE
|
|
|
|
Commit f688bcd1f1 fixed slow scrolling with xf86-input-libinput on DolphinView.
However the commit also exposed a bug in the Dolphin scrolling
algorithm, which was previously hidden. This resulted in slow
scrolling in dock panels (Places and Folders), with both
xf86-input-evdev and xf86-input-libinput drivers, as well as libinput on
Wayland.
KItemListContainer::updateScrollOffsetScrollBar() relied on the view's
itemSize() method to compute the scrollbar's singleStep, but this QSize
was invalid for the dock panels' views.
We use a new itemSizeHint() method instead, which is always valid and
also adapts to the current icon size set in the view.
BUG: 365968
FIXED-IN: 16.12.0
REVIEW: 129409
|
|
Scrolling with libinput was unbearably slow.
QScrollBar is much better at scrolling than us, so let it handle it.
REVIEW: 128432
BUG: 357618
|
|
REVIEW: 126771
|
|
when setting a different "mouse wheel scrolls by" value in the
mouse kcm, the user expects every view to scroll more or less
accordingly (even if it's not strictlya text view)
This makes the scroll in dolphin take that into account
REVIEW:126718
|
|
If shift key is pressed along with scroll, scroll up/down by whole page.
REVIEW: 123596
|
|
|
|
|
|
|
|
REVIEW: 119001
|
|
|
|
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.
|
|
When resizing the window and when KItemListContainer::updateGeometries
is called before the scrollbar visibility is updated, a relayout is
triggered in `m_controller->view()->setGeometry` which updates the
scrollbar visibility and calls back to
`KItemListContainer::updateGeometries` again. Since the first call,
which has the wrong geometry (due to the incorrect scrollbar states),
updates the geometries of the scene and viewport after the second call
(which has the right geometry!!) returns, the final result is a size
that corresponded to the old scrollbar state before this commit.
This patch uses the new geometry of the view after updating it (since
it might not be the size we put in) and therefore makes the sizes
consistent.
BUG: 327709
FIXED-IN: 4.11.4
REVIEW: 113939
|
|
Before this commit, Dolphin reserved space for the scrollbar spacing
even when no scrollbar is visible resulting in a ugly gap in the view
when:
1. the theme uses QStyle::SH_ScrollView_FrameOnlyAroundContents and
2. the theme has a positive PM_ScrollView_ScrollBarSpacing.
QtCurve can have both while Oxygen have 1 but not 2.
To reproduce the problem with Oxygen style. Replace the
`width += ....` (which returns -2 or 0 for Oxygen) with `width += 2`.
See more info here:
https://github.com/QtCurve/qtcurve-qt4/issues/9#issuecomment-28630517
CCBUG: 306631
FIXED-IN: 4.11.4
REVIEW: 113902
|
|
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
|
|
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
|
|
Up to now the view-engine only provided a model-implementation that
supports file-items. The view-engine always had been designed to be able
to work with any kind of model, so now a KStandardItemModel is available.
The plan is to convert the places panel to the new view-engine. It should
be no problem to fix this until the feature freeze - in the worst case
the places-panel code could be reverted while still keeping the
KStandardItemModel changes.
|
|
- Move all private headers from the kitemviews-directory into
the 'private' subdirectory.
- Get rid of DolphinDirLister and just use a directory-lister
internally in KFileItemModel.
- Minor interface-cleanups for signals
|
|
Usecase:
- No scrollbar is shown
- Window size will be decreased so that a scrollbar gets necessary
The decreased window size minus the space required for the scrollbar
results in a relayout of the items. In 99 % of all
cases a decreased window size won't result in showing more items in parallel in
comparison to a larger window size. However in the remaining 1 % this can
happen (e.g. see bug 293318 for a sample). This results in an endless loop as
now no scrollbar is required anymore, the layout changes again, the scrollbar
is required again, ...
BUG: 293318
FIXED-IN: 4.8.1
|
|
(cherry picked from commit dbf0bfffa72c190ed1c8b406c65c9e67b6f65d4f)
|
|
REVIEW: 103381
|
|
The folders panel has been adjusted to use the new view-engine.
A lot of things don't work yet, but are mostly minor issues that
should be fixable during the next 10 days.
|
|
Use only 1/4 of the scrollbar-page-size when the mousewheel
is used.
BUG: 284646
FIXED-IN: 4.8.0
|
|
Currently only a smoothscrolling was provided into the
scroll-direction, but not in case of the details-view where a
horizontal scrollbar might be shown too.
Some minor adjustments of the private KItemListSmoothScroller interface
will be done later...
|
|
Prevent unnecessary calls to visibleRolesSizes() when
expanding items. Also the performance has been improved when
resizing the window.
|
|
If an item does not fit into the available width/height a scrollbar
should be provided (e.g. typically this represents the horizontal
scrollbar in the details-view where the width can be larger than
the than the visible width).
Currently the interaction with the scrollbar is not implemented but
this will be a quite minor task in comparison to this patch.
|
|
|
