| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
The QSet range constructor requires Qt 5.14.
In `DolphinView::slotHeaderContextMenuRequested()` the conversion from
QList to QSet was pointless, so we just use a QList now.
|
|
|
|
BUG: 423326
FIXED-IN: 20.08.1
|
|
Unfortunately licensedigger does not strip the trailing * characters.
While at it, use a common style for all source files.
|
|
After porting from QFontMetrics::width() to QFontMetrics::boundigRect().width() in system/dolphin!10 we have a visual bug on selection rects, that can be seen on details and compact modes.
While from https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/ the use of `boundingRect()` would seem the right option to use (and I struggle to get the difference between the two methods when applied to a whole string and not a single char), in this case the `horizontalAdvance()` seems to return the value we need.
BUG: 421973
FIXED-IN: 20.07.70
|
|
After porting from QFontMetrics::width() to QFontMetrics::boundigRect().width() in system/dolphin!10 we have a visual bug on selection rects, that can be seen on details and compact modes.
While from https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/ the use of `boundingRect()` would seem the right option to use (and I struggle to get the difference between the two methods when applied to a whole string and not a single char), in this case the `horizontalAdvance()` seems to return the value we need.
BUG: 421973
FIXED-IN: 20.07.70
|
|
While the documention says to port to QFontMetrics::horizontalAdvance(),
what we actually need is not the horizontal advance, but the width of
the text. So we need to port to QFontMetrics::boundingRect().width().
Quoting from https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/:
"Since it was not clear from the confusingly named function QFontMetrics::width()
that it actually returned the horizontal advance, instead of the bounding width,
this method is now obsolete.
You must port to either QFontMetrics::horizontalAdvance() or QFontMetrics::boundingRect().width().
Please make sure you are aware of the difference, and do not port
blindly. I am pretty sure that in most cases
QFontMetrics::boundingRect() is what you want, unless you are writing
custom text shaping/layouting code. Using the wrong function can cause
clipped text or text that suddenly wraps to the next line despite
calculating the width that it needs."
|
|
We need to pass the pixmap by address, not by reference.
|
|
|
|
Summary:
Tweak behavior introduced in D19471.
BUG: 404955
Test Plan:
Before:
{F8325282}
After:
{F8325283}
{F8325284}
Reviewers: ngraham, #dolphin, elvisangelaccio, #vdg
Reviewed By: ngraham, #dolphin, elvisangelaccio, #vdg
Subscribers: kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D29794
|
|
GIT_SILENT
|
|
loader scale it
I noticed that depending on the configured icon size it would spend a significant amount of time in KPixmapModifier::scale.
I don't see a point in requesting a fixed icon size and then scale it down manually as opposed to having the KIconLoader do the scaling for us.
Especially for SVGs it could then even serve us a properly rendered SVG for this size rather than a scaled down pixmap version.
Differential Revision: https://phabricator.kde.org/D22116
|
|
|
|
Summary:
This ensures that the filename extension is always visible, and also is just a
nicer way to elide file and folder names in general.
BUG: 404955
FIXED-IN: 19.12.0
Test Plan:
Details view: {F6648784}
Icons view with limited label height: {F6648785}
Reviewers: #dolphin, #vdg, elvisangelaccio, GB_2
Reviewed By: #dolphin, #vdg, elvisangelaccio, GB_2
Subscribers: GB_2, ndavis, rooty, elvisangelaccio, kfm-devel
Tags: #dolphin
Differential Revision: https://phabricator.kde.org/D19471
|
|
GIT_SILENT
|
|
Ensures the overlay is painted in the same icon state, especially the selected one so dark overlays turn white.
Differential Revision: https://phabricator.kde.org/D16307
|
|
Fixes a regression introduced by not using the selected state.
The views other than icon view actually do have a proper highlighted background.
Differential Revision: https://phabricator.kde.org/D15387
|
|
Otherwise for 22px icons on high dpi we will request either the wrong icons or scale them needlessly.
Dolphin requests a pixmap of 22px, this is then multiplied by dpr resulting in 44 which isn't a valid icon size (only 32 or 48 are).
Moreover, we will also hit the path where it will scale the pixmap to a proper icon size resulting in blurry icons
(and a performance penalty).
Differential Revision: https://phabricator.kde.org/D15260
|
|
This causes selected monochrome Breeze icons to turn white as this state is meant for when the icon is actually painted ontop of
e.g. a blue highlighted area in a menu
Since the advanced icon configuration (where you could choose a custom hint color and other effects) has been removed in Plasma 5.13
and more importantly the fact that Dolphin always tints the icon in the highlight color disregarding any custom icon effects settings
this is an acceptable change.
CHANGELOG: Fixed monochrome icons turning invisible when selected
BUG: 398014
FIXED-IN: 18.08.2
Differential Revision: https://phabricator.kde.org/D15255
|
|
There be rounding errors when scaling pixmaps when keeping aspect ratio
Differential Revision: https://phabricator.kde.org/D11319
|
|
Summary:
Adjust calculation of icon pixmap Y value; now based off center of text label bounding rectangle. Previously, icons appeared top-aligned when text size was larger than icon size.
Centering is done by obtaining the center point of the text frame (`m_textRect.center().y()`) and setting the top `Y` point of the icon to one-half of the scaled icon height (`m_scaled_PixmapSize.height()`) Division is done by `2.0`, to ensure calculations are done with floating-point math, in keeping with `QPointF`, which returns floating-point values.
Also includes an adjustment named `midlineShift` (contributed by @zzag), which takes into account the font's midline in respect to the center of the text frame. Certain fonts (i.e. Noto Sans) can have a slightly offset midline, resulting in imperfect alignment of the icon. This small adjustment resolves that potential issue.
See before and after screenshots.
{F5764918}
Before, showing misalignment (with and without debugging wireframes)
{F5764920}
After, showing correction
BUG: 390771
Test Plan:
-- Compile Dolphin with patch
-- Increase system font size by several points (i.e. 15pt)
-- Check that Places panel icons remain centered with the text label
-- Select Compact View mode
-- Adjust icon size slider to minimum
-- Ensure that icons also remain centered in file listing
-- Check several combinations of icon size & font size to ensure centering is consistent
Reviewers: #dolphin, ngraham, cfeck, elvisangelaccio
Reviewed By: #dolphin, ngraham, elvisangelaccio
Subscribers: zzag, elvisangelaccio, #dolphin
Differential Revision: https://phabricator.kde.org/D11650
|
