Each screen has its own WindowHeap. So setting WindowHeap.activeClass
won't be visible on other screens.
In order to address that limitation, we could monitor
Workspace.activeClient property.
BUG: 455974
We use the PMF syntax so the isValid() check is unnecessary as the
compiler will notify about wrong signal at compile time. It makes
writing autotests feel less boilerplaty.
It adds more test cases in OutputChangesTest, particularly swapping
outputs.
Swapping outputs is an interesting case because outputs can temporarily
overlap so workspace()->outputAt() can return wrong output and the
window is going to stick to wrong output.
re-trigger the edge *only* if the user keeps the mouse still for at
least edges()->reActivationThreshold() - edges()->timeThreshold()
so that the user has to actually keep moving.
if the user keeps moving the cursor in the direction of the edge, it
wion't continuously retrigger it
BUG:457280
the Drag attached was set to active in a taphandler which didn't
accept touch, breaking drag and drop on wayland+touch
moving the logic on the other handler makes it work everywhere
This required a bit of a magic on the WindowHeap side to store and
restore global position of a WindowHeapDelegates' window thumbnails.
An additional property bool animationEnabled on a delegate level enables
the heap to restore position without playing unneeded initial animation,
just like the heap itself.
Windows that are being dragged or already returning form a drop are
positioned higher than others on a z-stack.
BUG: 453995
..so that they always match in size, regardless of different
combinations of drag&drop and animation states.
And also fix selected property to use id-qualified access.
Currently the Workspace processes output updates as they occur, e.g.
when the drm backend scans connectors, the Workspace will handle
hotplugged outputs one by one or if an output configuration changes the
mode of several outputs, the workspace will process output layout
updates one by one instead of handling it in one pass. The main reason
for the current behavior is simplicity.
However, that can create issues because it's possible that the output
layout will be temporarily in degenerate state and features such as
sticking windows to their outputs will be broken.
In order to fix that, this change makes the Workspace process batched
output updates. There are several challenges - disconnected outputs have
to be alive when the outputsQueried signal is emitted, the workspace
needs to determine what outputs have been added or removed on its own.
The proposed way to handle unplugged gpus allows us to ensure that
removed outputs' lifetime can be extended to the moment when the
Platform::outputsQueried signal is emitted.
Besides that, it's possible to extend this code a bit further to make
sure that output updates are batched when hotplugging multiple gpus,
e.g. after resuming, etc.
Separate trigger progress and semantic progress in gesture.
Move effect activation and desktop switching over to semantic progress.
Allow semantic progress to exceed 1 for overshoot in animations.
I've added VerticalAxis, HorizontalAxis, DirectionlessSwipe and BiDirectionalPinch gestures directions.
These are all combinations of other gesture directions that semantically work well together.
I've implemented these gestures as well as changed some labels and improved documentation,
Also,
Add vector signal to SwipeGesture
- Now only 1 GestureDirection enum
- Now only 1 registerGesture() call
- The 4 kinds of gesture (Pinch/Swipe) and (Touchpad/Touchscreen) in globalshortcuts.h/cpp are merged into 1 GestureShortcut
- Change from range to set of finger counts in gestures
No behavior should change, just a refactor.
When we have 0 opened apps, tab box only shows "Show Desktop". That element is a
special entry in the alt+tab list for minimizing all windows. When highlighting
it, panels temporarily become hidden, which does not make sense to do when it is
the only item in the tab box. In this case, do not temporarily hide the panels.
This makes it possible to show the input method when using a client that
doesn't support Wayland input methods (e.g. Xwayland).
This adds 2 dbus API entry points:
- activeClientSupported property: That tells us if the current client
doesn't support text-input-v*
- forceActivate method: forces the activation of the input method. This
configures the input method in a state that we can use to forward the
input method's keystrokes to the client, emulating a hardware keyboard.
BUG: 4399911
