Skip to content

containmentlayoutmanager: don't enter edit mode without activefocus

Christoph Wolk requested to merge cwo/plasma-workspace:containment_press_edit into master

Reason for the change

ItemContainer enters edit mode on pressAndHold for desktop widgets not set to immutable. This causes a problem with menus that open on press - the container will not receive further mouse events that now go to the menu, so it still considers itself pressed and unmoved the whole time, and goes into edit mode after a while, exiting the menu. This makes on-press menus in desktop widgets borderline unusable, and even if the user manages to be quick enough to activate the desired entry during the pressAndHold duration, it'll still enter edit mode unless the user also does a full click on the applet afterward.

We can circumvent this particular case relatively easily by listening to the container's activefocus changes - the popup opening does not cause a focusOut event, but it does take activeFocus away from the container, so if we stop the timer in that case, it works out as it should.

Test plan

  1. Put a widget with onPressed menu on the desktop (e.g. Notifications widget showing a dolphin copy finished notification, which has a "More Options" menu)
  2. Click the menu-opening button
  3. widget enters edit mode a little later / widget doesn't do that.

Screenshots or screen recordings

N/A

Bugs fixed

CCBUG: 416909

This does not solve all cases of edit mode activating when it shouldn't, but solves the menu issue and seems like reasonable behavior. Cases where the user might want to pressAndHold and element (e.g. pushing down on a spinbox button, grabbing a scrollbar early to scroll by moving the mouse a bit later etc.) need different handling (and at the moment I don't have a good idea how to solve these), but are more limited as if the pointer actually moves (selecting text or scrollbar scrolling with click-and-drag do not usually trigger the issue).

Merge request reports