| Age | Commit message (Collapse) | Author |
|---|
|
|
|
certain glyphs
In the Details view the name (text) column could appear vertically off-center for file names containing certain Unicode glyphs (for example "』"). The issue is caused by a mismatch between the generic font metrics ascent and the actual ascent of the rendered QTextLine for that glyph, which shifts the baseline and thus the visual vertical centering.
This change computes the QTextLine ascent for the (single) layouted line and adjusts the vertical position by the difference between the font metrics ascent and the line ascent. The adjustment is applied only for the name (text) role so other columns are unaffected.
BUG: 512152
|
|
aba0de7301b060c40d543adbaa8d53cf69a9d7ee re-introduced the usage of QFontMetrics::boundingRect(QString) for calculating the size of the last line of a filename. ..Unfortunately, that function uses a different code path from QTextLayout, and arrives at a shorter width for a line of text.
Meanwhile, QFontMetrics::size(QString) internally uses QFontMetric::boundingRect(QRect, int, QString, ..), which has been documented as "The bounding rectangle returned by this function is somewhat larger than that calculated by the simpler boundingRect() function. This function uses the maximum left and right font bearings as is necessary for multi-line text to align correctly."
I have empirically confirmed that QFontMetricsF::size and QTextLine::naturalTextWidth return the same floating-point value given the same input, and QFontMetrics::size does internally use QTextLine::naturalTextWidth through qt_format_text.
BUG: 432530
|
|
In editedRoleChanged.
This can happen if updateTextsCache has not yet be called before
editedRoleChanged in tests notably.
|
|
Found via `codespell -S "*.desktop,*.po,*.svg,*.xml,./po" -L aparent,childs,goup,lokal`
|
|
When editRole is changed, as in we start renaming an item,
we should clean up the hover effect. Otherwise
we'll have a weird glitchy look.
BUG: 508388
|
|
Since we never set the background color of the branch indicator to
something different now,
we can just let its color to stay as default.
|
|
Due to the new focus changes, our background highlights are more
transparent.
This means that the selected icon color is wrong, since
it's meant for fully opaque background
We should color the icon only when the element is pressed,
which is the only time we use fully opaque background.
BUG: 508418
|
|
We should use styleOption().iconSize instead of iconSize(), since
the styleOption returns always the correct size depending on
if we are showing previews or not.
In DolphinItemListView we set the iconSize based on the
previewSize or iconSize, and the styleOption().iconSize is
whichever value it is here.
KItemListWidget::iconSize always returns the settings.iconSize
BUG: 508352
|
|
When QFontMetrics::boundingRect().width was replaced with QFontMetrics::horizontalAdvance() in 76a46fd9094b17eb99e8a42cca8562fdc0b3814c, an extra line (formerly introduced by a203c271161ce953354b9e0722492605a4d17415) was changed as well.
Unfortunately, boundingRect().width is the correct function to use for calculating the size of the last line, while horizontalAdvance would be correct if we were laying it next to the previous line instead of below the previous line.
BUG: 432530
|
|
This adds a new selection effect that is similar to what we have in QtQuick file item views.
There are also changes to some usability: Instead of only the icon and text being the clickable area in icon and details mode, the whole selection is now the clickable area.
Otherwise the usability should stay the same, it's mostly a visual change.
See also: https://invent.kde.org/teams/vdg/issues/-/issues/94
|
|
Introduces a setting in Content Display Tab that allows to choose how
filenames are truncated when they do not fit in the maximum filename
length, i.e elide.
BUG: 504795
|
|
|
|
|
|
This allows to keep the original pixmap in m_pixmap when resizing so it can have nice rendering when being resized and simplifies implementation
|
|
This consists in replacing the use of KIconUtils::addOverlay to custom
adapted function, based on KIconLoader::global()->drawOverlays previous
behavior.
BUG: 500428
|
|
Now all overlays icons in kitemviews are added in
KStandardItemListWidget::updatePixmapCache.
data[iconOverlays] now contains icon names.
DolphinFileItemListWidget::refreshCache is the sole responsible of
setting the overlays either coming from KFileItemModelRolesUpdater or
KVersionControlPlugin.
This garantees consistency in rendering.
BUG: 497372
|
|
That were introduced in:
a55c467fbb31d822d89722812388425327830377
38ab14c87a945153e683657483fa4bcf44d6b0fb
|
|
Also use dpr for icons.
Amends cebcf8db
BUG: 497576
|
|
In ye olden days, filenames were elided on the right. This prevented
seeing the filename extension and any suffix style text the user
included in the filename (e.g. "myfile 1", "myfile 2" and so on).
In 97f49347482519b9ad53b7596d7462e68b7c2e14, this was changed to elide
in the middle, fixing both problems and bringing Dolphin into Jakobs'
Law style consistency with MacOS Finder and Windows Explorer, and
possibly other file managers too.
However it worsened the situation for users who name their files such
that most of the information was on the left. After some complaints, it
was changed in 99cf24c03def1c0722ba8dbd86a27b9dbc521f43 to right-elide
again, but excluding the filename extension.
Unfortunately user complaints have continued. At this point it's clear
that nothing will satisfy everyone due to diversity of file naming
styles. In such a situation, Jakobs' Law consistency with the rest of
the industry is the best solution short of making it configurable,
which has its own drawbacks.
Accordingly, return to middle-elision.
BUG: 497664
CCBUG: 404955
FIXED-IN: 25.04.0
|
|
This commit implements mirroring of the details view mode for right-to-
left languages. This is the last of the Dolphin view modes which did
not adapt to right-to-left languages correctly.
Implementation-wise this is mostly about adapting the math so all the
information is placed correctly no matter the view mode or layout
direction. While most of the view actually changes the painting code
for right-to-left languages, for the column header I decided to keep
the logic left-to-right and instead reverse the order of the role
columns.
To implement this mirroring I needed to rework quite a bit of logic, so
I used the opportunity to fix some bugs/behaviur quirks:
- Left and right padding is now saved and restored separately instead
of only saving the left padding
- Changing the right padding no longer disables "automatic column
resizing".
- The grip handles for column resizing can now be grabbed when near the
grip handle instead of only allowing grabbing when slightly to the
left of the grip.
- Role column headers now only show a hover highlight effect when the
mouse cursor is actually above that role and not above the grip
handle or the padding.
- There is now a soft-boarder when shrinking the right padding so
shrinking the padding "below zero width" will no longer immediately
clear automatic resize behaviour. So now it is possible to simply
remove the right padding by resizing it to zero width.
BUG: 449211
BUG: 495942
# Acknowledgement
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.
|
|
Suppose we are renaming file i and the new name will be sorted after
file i+1. We are now pressing ArrowDown to immediately start renaming
file i+1. However, because of the sorting we would not actually end up
renaming what used to be file i+1. What would happen is that editing
would be started in dolphinview.cpp:2065. However, after 100 ms the
timer in KFileItemModel would fire, resulting in the model emitting
itemsMoved(). This would trigger doLayout() in
KItemListView::slotItemsMoved(). doLayout() resizes the
KItemListWidgets, wich causes the renaming to be canceled in
KStandardItemListWidget::resizeEvent().
Now, we start a new renaming operation for the correct widget after the
relayouting is complete.
|
|
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
|
|
|
