| Age | Commit message (Collapse) | Author |
|---|
|
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/
|
|
Previously during rename, the number of QChar is used for selection,
which might be different from number of unicode characters.
Test plan:
- create the file zz❤️❤️.txt
- rename the file
- verify that the first 4 characters are correctly selected, which
didn't work before the patch.
BUG: 466814
|
|
The latter is what most other projects use
|
|
|
|
|
|
|
|
This MR makes the selection marker to be shown on the right in RTL mode.
|
|
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
|
|
Prior to this commit, the activateSoonAnimation would not play for
folders using previews. That was because the hoverSequences of
folder previews would always take priority over the
activateSoonAnimation.
This commit prioritises the activateSoonAnimation for the quick
moments in which it is active.
|
|
This commit adds an animation for folders that makes clear that
they will open or expand soon. This is the case when the option to
open folders during drag operations is enabled and a user drags an
item on top of a folder.
The animation goes like this:
- Replace the folder's icon with the "folder-open" icon
- Go back to the folder's original icon
- Replace the folder's icon with the "folder-open" icon once more
|
|
|
|
When possible, use the devicePixelRatio from the scene which on Wayland
unlike the QApplication will properly support fractional scaling.
A KItemViewsUtils class is introduced that can be reused elsewhere.
|
|
Currently multi-line file names in dolphin only display a single
line when renaming. This commit ensures multi-line filenames have
all lines displayed by calling `document()->adjustSize` in
`KItemListRoleEditor::autoAdjustSize`, and by calling the latter
function after setting up the editor.
BUG: 452587
|
|
|
|
BUG: 422998
CCBUG: 444747
|
|
|
|
|
|
selected widget on focus change
|
|
|
|
Instead of using the one from QApplication, use the one from the window.
|
|
* 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
|
|
|
|
When not using the full row highlight, the text of non-name columns
in details view mode was wrongly colored in a way that pretended
that the full row selection highlight was active.
When it isn't active we use the normal color that we generally use
when the additional information is not within the selection
highlight.
|
|
In d3839617193e92463806580699caa595c892b8a6 the details view mode
was changed in a way that made the full row of an item the click
target instead of only having the item's icon and text be the
representative clickable area of an item.
This commit makes this new behaviour optional through a setting
which can be changed in Dolphin's settings dialog.
The explanation for introducing yet another setting in this case is
as follows:
While the introduced change is an improvement for many typical
workflows, there are some workflows for which this new behaviour
is problematic. Quite prominently a usage of Dolphin that tries
to maximise information density is made worse by the change because
now side padding is necessary to click the view's background. While
the side padding is and was optional, disabling it made switching
the active view in split view mode more difficult among other
things. For a more complete discussion about the issues, please
check out the bug report(s) and the discussion in Dolphin's gitlab
issue with number 34.
Co-authored-by: Ivan Čukić <[email protected]>
BUG: 453700
FIXED-IN: 22.12
|
|
|
|
This commit changes it so the sizes of selection rectangles and hover
highlights in compact and details view mode is identical for all items.
Before this commit, selection rectangles in lists would have varying
indentation of the left edge of the selection rectangle depending on
the preview image's width-to-height ratio. This would cause a sort of
"ragged edge" in both compact and details list view when multiple items
were selected.
This commit doesn't change anything about icon view mode.
BUG: 453046
|
|
Since it actually adds padding on both left and right sides,
"Side Padding" might be more accurate.
This change is also propagated to variable and method names.
BUG: 453172
|
|
|
|
This reverts commit 3ce9d1d19e081fbb9acf020f15652175673bcf5c.
This reverts commit ddba4f5fd88c4fa855e3f2eb0d9d95a6290d150a.
Aside from the two bugs mentioned below, this also fixes another
regression: The spacing on the left of the view does now once again
follow the size of its column header.
BUG: 451704
BUG: 451341
|
|
|
|
|
|
|
|
BUG: 449211
|
|
When calculating layout geometry based on the pixmap size,
one needs to divide by `devicePixelRatio`
|
|
Avoids a text rect taller than the area that actually contains text,
as can be seen by hovering files in a folder with "additional roles"
that a given file does not contain.
|
|
Current implementation of the zooming animation is a bit buggy.
This MR fixes the following issues:
* in the Icon view mode, the icons sometimes "jump"
* in the Compact view mode, the labels sometimes are cut off
BUG: 449179
|
|
I failed to notice that the changes didn't apply cleanly. With this
commit everything should be a-okay again.
|
|
|
|
This reverts commit 7908aff3b5ebe4484d391c1fc4797e9dae2300b2.
Reverting this commit will fix the issue of not being able to rename
the last file in Details View and will also make the items in Details
View and Compact View have the same height.
BUG: 447215
FIXED-IN: 21.12.2
|
|
This commit implements full-row selection and hover highlights for the
details view mode.
This commit also contains fixes for 444680, 444753, both uncovered
during this change.
BUG: 181438
BUG: 444680
BUG: 444753
FIXED-IN: 22.04
|
|
|
|
Under some conditions, when zooming, only the size of the icon is changed, but not the entire item, which visually doesn't look good. The main idea of this MR is that when scaling the whole element should be resized, not just the icon, so I came up with some zoom levels for the main icon sizes. With this commit, zooming will resize the entire element, even if the resizing of the icon doesn't affect the size of the entire element.
|
|
This shows a slideshow of thumbs when the user hovers a file item.
|
|
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
|
|
Apparently the icon was not null, because the mimetype was known.
But there was no icon associated with it and we got an
icon which is not null, but has a null pixmap.
|
|
|
|
|
|
|
|
|
|
|
