When something is selected, we pre-generate the drag image so that it's
ready if the user starts a drag. But this is asynchronous, and while
it's generally very fast, a determined with swift fingers can start the
drag before it's ready. There's two major ways that this can happen:
- The user has just moved one or more files, and tries to drag them
again. In this case, they're still selected, the old dragImage is
reused, but as they start from a different position now, the hotspot
adjustment may put it ways away from the pointer.
- The user clicks and drags an icon that was not previously selected.
In this case, there's no image at all, and the icon just vanishes
while dragging.
Both are somewhat challenging to reproduce, but I've found the second
is easiest immediately after plasmashell start. But I've reproduced both
outside of that situation as well.
We do two things to fix this: for the first, we generate the dragImage
not just when the selection changes, but also when icons are moved -
this way it should be ready if the user starts dragging again. Second,
we track on the delegate whether the image is being generated, and skip
starting the drag if it's not. This is fast enough that it should be
ready once the next pixel is reached, so for the user there's no
perceptible difference - effectively just a marginally larger
startDragDistance, but it makes sure that when the drag starts, the icon
does not vanish.
BUG: 527529
Currently, FolderView always opens its context menu at the pointer
position. This makes sense for opening the menu with a right-click, but
the same logic is used when the Menu key is pressed. (If nothing is
selected and we open the containment's context menu instead, the menu
opens at (0,0). This is not how the Menu key works in Dolphin (where it
appears to the bottom right of the current item), somewhat inconvenient
with keyboard navigation (as the pointer position may be far from where
the user is looking) and can be misleading, as it makes it seem like the
menu applies to the file where the context menu is attached to, rather
than the currently selected files.
Instead, we pass in whether the menu should open at the cursor position
or not, and if not, open at the bottom right of the visualParent. This
gives almost identical behavior to Dolphin with regard to where the menu
pops up (with rubberband selection, the two may disagree which is the
currentItem).
BUG: 526282
Ctrl+Shift+N creates a folder on the desktop, but unlike in Dolphin the
"Folder…" entry in the "Create New" menu doesn't show the shortcut.
KNewFileMenu shows the shortcut of the action passed to
setNewFolderShortcutAction(). Dolphin passes its Create Folder action,
but Folder View has none: its shortcuts are handled by the ShortCut
event filter, because actions don't receive key presses in the QML
view. So pass an action that only carries the standard Create Folder
shortcut. It isn't attached to anything, so Ctrl+Shift+N still creates only
one folder.
BUG: 473045
ItemListDelegate may show tooltips. When you scroll the list, this may
interfere with the list view's hovered check and unset the currentitem.
Instead, also check whether the delegate containsMouse, which is still
true when scrolling. This makes both wheel and touchpad scrolling work
properly, and selects the item the pointer lands on.
FolderView tracks the pointer position on press, and uses that
information on pointer move to start a drag or rubberband. However,
when something resets the model (such as when a lot of files are deleted
and each deletion resets the model), this information is reset. For the
most part, this means that you can't rubberband while the deletions
happen (you press, the press is reset, you move the mouse and nothing
happens) which isn't great but also not too bad. However, if you manage
to time it just right that the click and move happens fully within the
short period between resets, you'll start the rubberband, then the reset
changes the active rubberband to start at -1, -1 instead of the position
you actually clicked.
A somewhat easier to trigger condition is if some other process removes
or adds files to the desktop while the user is mid-rubberband, such as a
browser downloading things. In that case, the origin will also move from
the clicked position to the top left while the rubberband is active.
This is quite weird. So instead just update the rubberBand's origin if
the rubberband is not active yet. We keep resetting the press state
otherwise to keep the change as small as possible. This means that
starting a rubberband while a large number of files are quickly
added/removed one-by-one will continue to not work unless you get the
timing exactly right. But having to briefly wait while the system is
clearly doing something is less bad than suddenly changing the
rubberband region mid-operation, and changing this can wait for the
new desktop implementation (if feasible then).
BUG: 526073
FIXED-IN: 6.9.0
Only add the "Manual" entry when configuring the containment. The
Descending/Folders first checkboxes now check the selected mode
instead of the combobox index, since index 0 is no longer always
"Manual".
BUG: 513880
With "Show application icons on window outlines" enabled, the icons
stay at the small icon size (16 px at 100% scale) no matter how large
the panel or the windows are.
Size the icon from the smaller side of the outline, keeping the same
spacing as before, and raise the cap to iconSizes.medium. Small window
outlines get the same icon size as before.
BUG: 518625
Instead of keeping a copy of Kirigami's About page adapted to
KPluginMetaData, pass the widget's metadata to Kirigami.AboutItem.
This also brings Kirigami's reflowed license text, so the license no
longer shows the hard line breaks of the license file.
BUG: 486305
We elide long titles when space is unavailable on the panel, instead
of moving other widgets off of the panel, and cap the whole widget
at 20 gridUnits regardless.
BUG: 456148
preferredWidth() and preferredHeight() already compute a minimum of
one cell (or four rows of the list view) when called with
forMinimumSize = true, but the Layout.minimum* bindings passed
root.inPanel instead. Outside of panels that meant the minimum size
was the full preferred size, so the smaller minimum only ever applied
to the panel popup.
BUG: 515561
Adds a signal so that whenever a file is deleted/moved to trash, we
know to remove it from positioner configuration.
On listing completion, we now get a list of items that actually
exist, so that positioner can remove the extraneous files.
Iterate over all resolutions and skip files that do not exist
in our position array during saving.
BUG: 469445
CCBUG: 507079
FIXED-IN: 6.8.3
Previously we were using Text.Wrap, which means "prefer word boundaries
for wrapping, but wrap in the middle of a word if that's impossible".
In Qt 6.12, dashes and em-dashes are now more aggressively considered to
be word boundaries. There's nothing wrong per se about this change, but
it doesn't work super well for the task manager where there's a lot of
punctuation and space is very limited. So let's switch to
Text.WrapAnywhere to maximize space efficiency.
BUG: 526972
FIXED-IN: 6.8.2
When the "Keep Open" button pins the Dwell Clicker window
then choosing the next type of click should not close
the applets window.
This enables to pin the window and use it as floating
dwellclicker window to switch between the clicks saving
one additional click otherwise needed.
When the screen with the panel goes away for a moment, for example when
the monitor is turned on only after the computer has resumed, the panel
is moved to another screen and back. When the popup is shown afterwards,
its Screen attached property still refers to the other screen, so the
height is limited by that screen. Screen is updated right after that,
but the popup keeps the smaller size and the menu stays too short, also
when it is opened again.
It only shows when the other screen is small enough. In my setup the
panel is on a 2560x1440 screen and a 1024x600 screen is placed below it.
The menu needs about 640 px, but 90% of 600 px is only 540 px, so the
list has to be scrolled.
This became visible with b8fc07ab80, which limited the popup height
to a fraction of Screen.height.
Use the containment's screen geometry instead, for the height and the
width limits. It follows the panel when it moves between screens and
does not depend on the popup window, so it already refers to the right
screen when the popup is shown. The task manager also relies on it to
know which screen it is on. For a widget on the desktop the containment
is that screen's desktop, so the limit still comes from the screen the
widget is on.
BUG: 527385
Searching System Settings for "drag and drop" (or "drag", "drop")
lists the Mouse page, which has no drag-and-drop setting, and does not
list General Behavior, which has the "Drag and Drop" group that
controls what happens when files are dropped.
BUG: 518455
We use PreserveAspectCrop for the 16:9 card preview of the wallpaper
instead of stretching them. We also request a square thumbnail so that
wallpapers narrower than 16:9 come at least as wide as the card and do
no need to be upscaled.
BUG: 478784
On a vertical panel, the size spinbox shown in edit mode for a
non-flexible Panel Spacer cannot go beyond the panel's thickness;
we instead use the panel length regardless of orientation.
BUG: 518799
The label is created with a createObject call, which fixes the
label and icon values in place on creation. This commits adds
a binding so that they update over time.
BUG: 522322
BUG: 501660
BUG: 506247
ListOfGridsView is used for the All Apps page if kickoff is set to show
everything as a grid. As the name suggests, it's a ListView whose
delegates are full size gridviews, so themselves are not scrollable.
They each contain their own Kirigami.WheelHandler, which is set to not
blockTargetWheel. This works sort of ok for scrolling with an actual
wheel but totally breaks when using a pointing stick/push to scroll,
where it only works if you start over a ListView section header and
not over any content, and with touchpad scrolling it's incomprehensible
jank: sometimes it works, sometimes it doesn't at all, sometimes it
scrolls but at a glacially slow pace, sometimes it works but only with
a second delay...
Instead, we can just tell the Kirigami.WheelHandlers to scroll the
ListView directly, rather than hoping no blockTargetWheel works out.
This makes it work properly with wheel, push to scroll, touchpads and
touch. And as this is the only thing that uses blockTargetWheel, we can
get rid of that now.
BUG: 526911
FIXED-IN: 6.8.2
since the activity switcher/widget explorer are dock windows,
positioning
is completely managed by layershell, and we can't put it on top
of another panel, so if there are horizontal panels, make the
window less tall to accomodate that.
BUG:527158
When the highlight effect is enabled, task manager sends Kwin
instructions to highlight a window when a tooltip is hovered, and
to clear it if it is not hovered. This works fine, but only as long
as the unhover signal is always emitted before the hover signal for a
different window. If not, when moving between tooltips, it will flash
the second window and immediately unhighlight it when the previous
tooltip sends its unhover signal. This can happen rarely with thumbnails
enabled (as there is a safety area between the tooltips that usually
gives enough time to get the signals in order), but is trivial to
trigger if the effect is enabled without thumbnails.
Instead, store the last set of window ids that are highlighted, and
cancel the highlight effect only if an unhover event actually applies to
the current highlight. This reimplements parts of !2816, which also
handled the signal race as part of a larger change that was never
merged, in a more targeted fashion.
BUG: 527229
FIXED-IN: 6.8.2
A replacement FolderModel can register its screen before the previous
model is destroyed. The old model then removes the registration used
by its replacement, causing desktop icons to disappear.
Track registrations by owner and remove the mapping when the last
matching owner releases it. Disconnect mapping signals while changing
a model's folder URL, then refresh its filter after registration.
Add regression tests for overlapping models and final-owner cleanup.
BUG: 527226
FIXED-IN: 6.8.2
ItemGridDelegate (for kickerdash) and SideBarItem (for kicker) use
attached Drag. We set the mimeData from the url (as well as an internal
one where appropriate). But not all delegates have an url; in particular
the system actions (power/session) do not; they're only internal to
kicker and don't have an url representing them for elsewhere. This
causes a runtime warning that an empty Url is not a valid Url, as
attached Drag actually parses the test/uri-list mimetype.
Instead, we only add that mimetype if the url is not empty.
Kicker, when placed on a panel oriented at the end of the reading sense
(i.e right-edge in LtR, left-edge in RtL) flips the arrangement of most
parts of the widget to match the new orientation of the popup: favorites
and higher-ranked runner columns start closer to the applet. But not
everything should be mirrored; the delegates themselves should still
look normal (and have e.g. icon-text order in reading direction). We
currently implement this by passing things around and setting
LayoutMirroring a-la-carte as needed. But it's tricky to get everything
right. In particular, if we end up with a scrollable popup, it places
the scroll bar not in the area reserved for that, but overlaps the
content on the other side.
Instead, use the simpler approach and have LayoutMirroring inherit down
from the top, and only set it again right when we need to change it
again - on the delegate. This solves the issue and is a bit shorter too.
BUG: 525994
FIXED-IN: 6.8.1
fae19c97e5 added inner right margins to
ItemListView when used in runner columns to provide consistent spacing
between the listview and surrounding elements. (Except for the final
column, where the applet popup margin can take that role.) But that fix
does not cover the regular menu and its popups, which still have the
highlight bump into the scrollbar if the menu is larger than the
available space, and similarly if the final runner column is scrollable.
Instead, also add the inner right margin also if the listview is
scrollable, whether as the final column or not.
