Fixes for macOS#34
Open
kbaker wants to merge 1456 commits into
Open
Conversation
githubuser0xFFFF
force-pushed
the
master
branch
7 times, most recently
from
3ee0c84 to
54c2bd0
Compare
githubuser0xFFFF
force-pushed
the
master
branch
2 times, most recently
from
cbb46f9 to
6362d14
Compare
Sometimes the synchronous calculation of the rectangular area fails
memory leak
saveState() may use the floatingDockContainer to be deleted
remove dock container
* fix side bar state being incorrect during restore * isVisible is invalid during restore state * Make visibleTabCount function consistent with hasVisibleTabs. Add a bit of documentation. --------- Co-authored-by: Syarif Fakhri <fakhri.s@duerr-ndt.com>
…SideBar::visibleTabCount() and CAutoHideSideBar::hasVisibleTabs()
…; with QWidget::activateWindow
…ing back to QApplication (#812)
* Fix ADS_VERSION support for builds without git dependency - Move CMAKE_MODULE_PATH outside if(NOT ADS_VERSION) block so it's always available - Parse ADS_VERSION to set PROJECT_VERSION_* variables for Versioning.cmake - Update Versioning.cmake to use predefined version when available, fallback to git This allows building with -DADS_VERSION=X.Y.Z without requiring git repository. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * Add ADS_PLATFORM_DIR option to customize output directory Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: ArtemNabok <nabok.artem@yandex.ru> Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
…a floating widget that contains only one single visble dock area (#816)
* Initial plan * Fix drawing artifacts when content widgets call winId() When a content widget (e.g. VTK/OpenGL) calls winId() to get a native window handle, Qt propagates native-window creation up the ancestor chain. This makes CDockWidget, CDockAreaWidget, and CDockContainerWidget all become native OS windows unexpectedly. Reparenting these native dock widgets during floating or resizing then causes drawing artifacts. Fix: set Qt::WA_DontCreateNativeAncestors on the content widget in CDockWidget::setWidget() to stop native-window creation from propagating up into the dock hierarchy. Co-authored-by: RubendeBruin <34062862+RubendeBruin@users.noreply.github.com> * Fix docking system to handle mix of native and alien Qt widgets Three targeted fixes for the native/alien widget mixing problem: 1. Revert WA_DontCreateNativeAncestors from CDockWidget::setWidget(). Setting it on the content widget created a broken native-inside-alien hierarchy: the QScrollArea (alien) could not clip its native child, so content escaped the scrollbox bounds; and alien CAutoHideDockContainer could not appear above the native content widget. Allowing natural propagation means QScrollArea also goes native, and OS parent/child window clipping works correctly. 2. Fix CDockContainerWidget::removeDockArea to use internalWinId() instead of testAttribute(WA_NativeWindow). WA_NativeWindow is only set when a widget is explicitly made native; widgets that became native through upward propagation from a descendant calling winId() have a real native window handle (internalWinId() != 0) but WA_NativeWindow may be unset. Setting their parent to nullptr would create a free-floating invisible OS window and cause drawing artifacts. 3. Fix CAutoHideDockContainer::collapseView: when the parent dock container is native but the auto-hide panel is still alien, promote the panel to a native window (winId()) before raise(). The OS always renders native child windows above a parent window's painted alien content, so an alien auto-hide panel can never appear above native sibling dock areas. Once the panel has its own OS-level window, raise() operates on OS Z-order and correctly places it above native content siblings. Co-authored-by: RubendeBruin <34062862+RubendeBruin@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
…rnal hide/show cycle by QWebEngineView. (#821) Co-authored-by: AlbertoM <ma-robox@users.noreply.github.com>
Add preferredAutoHideSideBarLocation property to CDockWidget that allows applications to specify where a widget should be pinned, overriding geometry-based detection. When unpinning, widgets with the same preferred location merge as tabs instead of creating new splits. Default is SideBarNone (existing geometry-based behavior preserved).
- If compiling with flag [-Werror,-Winconsistent-missing-destructor-override]
In DockManagerPrivate::restoreStateFromXml() the floating widgets were removed via removeDockContainer() and then queued for deletion with deleteLater(). When ~CDockContainerWidget() ran it would call removeDockContainer() a second time on the same container, tripping the Q_ASSERT(removed == 1) check in CDockManager::removeDockContainer(). Switch to CDockContainerWidget::removeFromDockManager() (introduced in upstream 544c624) so the container's back-pointer to the manager is cleared up front and the destructor becomes a no-op for the manager side. This keeps the LP360_AI workspace restore path crash-free until the equivalent fix lands upstream.
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.
* add dark versions of resource files * reload stylesheet on theme change * adjust dock overlay colors for dark mode, refresh dock overlay colors when theme changes * follow application palette instead of system scheme, remove Qt version constraints, add legacy behavior settings * fix text color of focused tab label for highlighting stylesheets * fix missing tab menu icon in focus highlighting stylesheet
…window drag (#844) Qt Advanced Docking System could not dock on Wayland: a client cannot position top-level windows and the global cursor position is unreliable, so the mouse-tracked floating-widget drag never worked. This adds Wayland docking by combining two mechanisms, selected by whether the drag stays inside its source window. Native cross-window drag (xdg_toplevel_drag_v1): - CFloatingDockContainer::startPlatformDrag() runs a compositor-driven drag via QDrag with the Qt main-window-drag MIME types, so a floating window is moved by the compositor and can be dropped onto another window. - Drop targets handle the drag in CDockContainerWidget dragEnter/Move/Leave/drop events, with a recorded drop-candidate fallback for compositors that do not deliver a drop event over the dragged window. - The drop overlays (CDockOverlay) and the in-window drag preview are rendered as child widgets of the relevant top-level window, because a Qt::Tool top-level cannot be positioned in screen coordinates on Wayland. - Floating containers use a native window with no parent on Wayland, and the DockManager stays-on-top emulation that would recreate window surfaces is skipped. In-window preview, native only when leaving the window: - While the cursor stays inside the source top-level window, a drag uses the familiar in-window CFloatingDragPreview plus drop overlays (no new window), driven by the reliable event-supplied position from the grabbing tab or title bar and confined to the source container. - When the cursor leaves the window, the preview is torn down and a real CFloatingDockContainer is created and handed to startPlatformDrag() while the press's implicit pointer grab is still held - a single continuous gesture. This covers both the tab (CDockWidgetTab) and title-bar (CDockAreaTitleBar) drag paths and applies to rearranging widgets inside floating windows too. - The attach offset that places the new window under the cursor is only honored while the toplevel is unmapped, so startPlatformDrag() runs QDrag::exec() without waiting for exposure, and the caller passes the surface-local grab offset explicitly - shifted by the window frame top and left margins - instead of deriving it from the unmapped window's (meaningless) geometry, so the grabbed content point stays under the cursor on both axes. Style sheets and overlay lifetime: - A Wayland floating container has no parent widget, so it does not inherit the dock manager's effective style sheet through the widget hierarchy. The style sheets along the dock manager parent chain are applied explicitly when the window is created, and CDockManager re-applies them on QEvent::StyleChange so a floating window keeps matching the docked content when the style sheet changes at runtime (an application-wide qApp style sheet is still applied by Qt automatically). - The drop overlays are reparented into the top-level window they are shown over and reparented back to the dock manager's window when hidden, so a dock-manager-owned overlay is never left as a child of a transient floating window that gets destroyed. Saved layouts restore the docked arrangement, floating-window sizes and their maximized/normal state, but not floating-window or main-window positions: Wayland does not let a client position its own top-level windows, so the compositor decides where restored windows appear. Non-Wayland platforms (X11, Windows, macOS) are unaffected: every behavioral change is gated on internal::isWayland(), and the shared drag-preview code keeps using QCursor::pos() and the existing window positioning off Wayland. Co-authored-by: Agent 01 <agent@jetperch.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…rectly from auto-hide state
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixed an issue where dragging a floating dock container over the main window would make the floating dock container spontaneously go behind the main window.
Fixed an issue where dragging a floating dock container or a floating drag preview would attempt to dock with other floating dock containers that were partially or fully obscured by the main window.
Fixed some clazy warnings.
Fixed some comments on the close of private structures.