+++ This bug was initially created as a clone of Bug #421540 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] This one's arguably a new feature, but I call it a bug, particularly the delete aspect as that's an unnecessary risk to existing rules. Perhaps it's because I'm a computer person used to working with a mouse/touchpad/trackball/etc, not a cell-phone person used to dealing with touch, but... I'm used to being able to double-click an entry to "modify" it, and now that doesn't work; double-clicking a rule does nothing. I have to slide the pointer several inches over to the right (75-inch 4K TV as a monitor, so it's /literally/ several inches on the display!) and hit the (relatively) small edit button in ordered to modify, instead of just being able to double-click anywhere in the (relatively) larger entry. Meanwhile, deleting seems to be much more dangerous now. There's no confirmation, and hitting the delete button means I'm focused all the way to the right on it, and don't see that the entry name to the left is different with the deletion so a different rule's delete button is now under my pointer. As nothing seems to have happened, my reaction is that there was no response and to try hitting the delete button again! Obviously, doing that repeatedly could quickly decimate my existing rules, instead of deleting only the one I initially intended to delete. (And that's not even considering the possibility of hitting it by accident.) Preferably there'd both be some sort of delete confirmation to avoid an accidental delete, and some sort of delete animation or something, so I can tell something happened even if I'm focused on the delete button and don't notice that a different rule filled the spot of the deleted one. But at least one of the two would be better than the current situation and should be strongly considered before a release with the new design. I'm just glad I /didn't/ hit that button again!
Adding the reorder button to the list too. The reorder button icon (ascii-art)... ^ = v ... appears to be two (or three) separate buttons, especially to someone used to having separate up/down buttons from before the redesign. I clicked the up-arrow to move a rule up, and there was no response. Clicking the down arrow did nothing either. Then I realized it was a single drag-only button now, and I had to /drag/ the thing! =:^( And moving-via-drag a rule several pages of rules up/down to the top/bottom is a serious chore! IIRC that was a single button-click before. (Right now it's even worse due to the currently dismal performance of the redesigned kcm; dragging up/down more than a page's worth means waiting for the entries to veerryyy leisuuurrlly scroll by one or a handful at a time, but that's bug #421540 and response speed will hopefully be far better before an actual release.)
Git commit 654d369e0e8b0eddc5b33f3c14430626476cbc0f by Ismael Asensio. Committed on 02/11/2020 at 18:09. Pushed by iasensio into branch 'master'. Use hand cursors on ListItemDragHandle This helps hinting that the handle is to be dragged to arrange the item M +2 -0 src/controls/ListItemDragHandle.qml https://invent.kde.org/frameworks/kirigami/commit/654d369e0e8b0eddc5b33f3c14430626476cbc0f
Adding the x11-only keyword