Linux: only raise floating widgets during an active drag

[kriben]

On Linux/X11 the CDockManager constructor connects a handler to QApplication::focusWindowChanged that, on every focus-window change, calls raise() on the dock manager, on every floating widget, and on the newly focused window. The original intent (#722) was narrower: bring the application and its floating widgets to the foreground only while a floating dock widget is being dragged over another application.

Reacting to every focus change makes this a self-sustaining loop. raise() restacks top-level windows, which on X11 can make the window manager move focus, which re-emits focusWindowChanged and re-enters the handler. Because all windows are raised on every pass, the z-order never reaches a stable state, so the windows keep restacking - visible as continuous flicker. It gets worse the more floating widgets exist, since each pass raises more windows and generates more focus transitions. The later QMainWindow/QDialog/CFloatingDockContainer type test only narrows which focus changes start the loop; once started it still runs unbounded (#785).

Fix: gate the entire raise block on a floating widget actually being dragged. Outside a drag the handler now returns immediately and issues no raise() calls, so it can no longer feed itself - no restacking, no flicker. The foreground behaviour during a real drag is unchanged and ends naturally when the drag finishes.

ADS already tracks this state internally
(FloatingDockContainerPrivate::DraggingFloatingWidget); this exposes it through a small public accessor:

bool CFloatingDockContainer::isDraggingActive() const;

Fixes #785.

[kriben]

When running the SimpleExample on Ubuntu 24.04 with i3 on X11 I would get endless restacking when creating multiple floating windows: resulting in the windows figthing endlessly for focus.

I think most window managers do some form of focus-stealing prevention, and refuse or defer a programmatic raise that isn't tied to recent user input. The window gets marked "demands attention" instead of actually being restacked/focused. That refusal naturally stops the loop: the app asks to raise everything, the WM quietly declines, nothing re-fires.

i3 is strict and trusts the client's raise/focus requests instead of second-guessing them. This leads to the is a raise() -> focus-change -> raise() loop.

As a bonus this fixes #785 for me.

[githubuser0xFFFF]

Thank you very much for your contribution.