childAtCoordinates() steps back by the layout's spacing until it finds
a widget. With a spacing of 0, which some third-party widgets set, the
point never moves, so dragging something over an empty part of the
panel froze plasmashell.
Always step back by at least 1 px.
BUG: 528228
Restoring the windows only un-minimized them, so the window that had focus came
back without it and typing went to the desktop. Remember the active window when
minimizing and activate it again after restoring.
BUG: 450137
Prevent saving incorrect icon positions while the desktop is still
setting up its screen geometry.
This fixes the following scenario:
- 'setPerStripe()' is called from QtQuick with a lower 'perStripe'
value (because the desktop geometry is not yet correct) while the
directory is being listed
- directory listing finishes (we skip saving the icon positions)
- 'setPerStripe()' is called again (from QtQuick) with the correct value
This can occasionally happen when turning off one monitor and turning on
another, depending on the hardware.
Behavior change: Saving is skipped when Plasma loads or the desktop
reappears on the screen. There is no need to save when the desktop
loads or reappears.
The list had a few problems, notably an erratic sorting that randomly change during and after searching for a layout.
While at it, refactor some code and port the models to C++.
SDDM 0.21 still runs its greeter on X11 and sets
QT_IM_MODULE=qtvirtualkeyboard, but since b1eed7f7 the theme only forwards
to Keyboards.KWinVirtualKeyboard, which only exists under a running KWin.
Qt Virtual Keyboard stays loaded as the input method, and because the theme
no longer instantiates its input panel, Qt creates its own
DesktopInputPanel, which pops up whenever a text field gains focus, a plain
mouse click included. The keyboard button was dead there as well, because
KWinVirtualKeyboard.available is false and its visible property never
becomes true.
Bring the X11 fallback back as a theme-private component: on X11
VirtualKeyboard.qml loads the Qt Virtual Keyboard panel that
plasma-workspace dropped in f1c83d15 (instantiating QtVK.InputPanel is what
keeps Qt from creating its own panel), on Wayland it keeps forwarding to
Keyboards.KWinVirtualKeyboard. The button is hidden when no virtual
keyboard is available at all.
The panel itself carries no animation: it is shown and hidden by animating
the loader that holds it, which slides it below the bottom edge while
fading it out. Keeping the animation in one place matters because Qt
Virtual Keyboard's own hide key turns InputMethod.visible off before the
theme is notified, and a panel that hid itself as soon as it became
inactive would disappear in a single frame instead of sliding out. The
panel is only deactivated once it is fully off-screen, so that hiding it
does not cut the animation short.
BUG: 527138
Scrolling past the first or last desktop asked the pager model to switch to the
current desktop, which toggles Show Desktop when that option is set for clicks.
Only change the page from the wheel handler when it is a different one.
BUG: 471241
The use-case for this has passed. Most devices appear as mass storage
devices.
The UI is not up to the expectations of something we would allow in
Plasma if it was introduced today. The end goal is for user to set
custom commands via an incredibly complicated UI that requires the user
to know how to use Solid predicates syntax.
At most it saves a few clicks it does not solve any unique problems on
it's own.
The code in the Device Notifier applet is left unchanged as actions can
still be shipped by applications or written manually. This brings it in
line to dolphin service menus.
This was discussed at the last Plasma sprint in Graz.
Pager's WindowModel adds a StackingOrder role (with rolename
StackingOrder), but the source model already has this role with
the same rolename. When we try to get the new property from qml for
a delegate, we get many warnings of the type:
qt.qml.propertyCache.append: Final member StackingOrder is overridden in
class QQmlDMAbstractItemModelData. The override won't be used.
The two properties (AbstractTaskModel's StackingOrder and pager's
StackingOrder) usually give the same result, so there doesn't seem to
break anything badly, but we can get rid of the warnings (and get the
value as originally inteded) by giving the WindowModel role a unique
name (PagerStackingOrder).
There is no QWidget to use as parentWidget on this QML path, so
plugins that need an owner for the QActions they return (such as
Dolphin's folder icon action via KFileItemActionPluginV2) got nullptr
and leaked them.
Pass the popup menu through KFileItemActions::setParentObject(), added
in KIO 6.32 (https://invent.kde.org/frameworks/kio/-/merge_requests/2427).
The menu is deleted right after the popup closes, which also frees the
actions. It is not set as parentWidget, since that is also used for job
dialogs that must outlive the popup.
CCBUG: 525162
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
