Project

General

Profile

Support #1036

Recent dockwidget redux causes main window to "walk" vertically upon invocation.

Added by Jim Turner about 2 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Trivial
Assignee:
-
Category:
-
Target version:
-
Start date:
December 03, 2020
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

Issue affects older Qt's (v5.7.1 tested), but not newer (5.15.1 tested). When exiting Audacious WITH at least one dock plugin running (either docked or floating), then restarting, the main window is positioned vertically upward (and leftward) by the height of the titlebar (and side decoration). Tested on 3 different window-managers. It's a known X11 problem (https://doc.qt.io/qt-5/application-windows.html#window-geometry), and Qt seems to be getting better at handling. I spent 3 hours trying to come up with a fix, but could not. What makes this really tricky is that it's inconsistant: I can easily "fix" it programatically for the case where at least one dock plugin is running, but that will break it for the case where none are running (will move DOWN vertically on restart), and I don't see any relationship between whether dock plugins are running or not vs when the window-manager decides to decorate the main window! I'm marking this as "support" instead of "bug", since it's not an Audacious bug, and seems to work in most recent Qt, but am asking you if you might take a look at it (what you changed when you implemented the new dock api) or have any ideas for a workaround.

Affects latest 11/28 git changes vs slightly older Qt's.

patch1036.diff (1.47 KB) patch1036.diff Jim Turner, December 03, 2020 22:31

History

#1 Updated by Jim Turner about 2 months ago

I took another look at this and this (patch seems to work for both old and new Qt).

Regards,

Jim

#2 Updated by John Lindgren about 2 months ago

I tested 4 different systems and don't see this occurring:

  • Qt 5.3.2, xfwm4
  • Qt 5.12.7, kwin
  • Qt 5.14.2, xfwm4
  • Qt 5.15.2, openbox

Maybe it's a specific bug in Qt 5.7?

#3 Updated by Jim Turner about 2 months ago

Could be, but this patch seems to FIX this issue on AfterStep, jwm, fluxbox, and icewm (tested) on both 5.7 and 5.12. The only one it didn't, that I had for testing was on Windowmaker.

If you decide to use the patch but want to be more kosher with it, you could perhaps do it instead as:

        toolbar->show ();
#if QT_VERSION < QT_VERSION_CHECK(5, 8, 0)
        int dock_count = 0;
#endif
        for (auto w : findChildren<DockWidget *> ())
        {
            w->show ();
#if QT_VERSION < QT_VERSION_CHECK(5, 8, 0)
            ++dock_count;
#endif
        }

        /* set initial keyboard focus on the playlist */
        m_playlist_tabs->currentPlaylistWidget ()->setFocus (Qt::OtherFocusReason);

#if QT_VERSION < QT_VERSION_CHECK(5, 8, 0)
        int x = aud_get_int ("qtui", "player_x");
        int y = aud_get_int ("qtui", "player_y");
        if (y <= 0)
                y = 25;

        if (dock_count > 0)
        this->move (x, y);
#endif
    }

    MainWindow::~MainWindow ()
    {
        QSettings settings (m_config_name, "QtUi");
        settings.setValue ("geometry", saveGeometry ());
        settings.setValue ("windowState", saveState ());

#if QT_VERSION < QT_VERSION_CHECK(5, 8, 0)
        aud_set_int ("qtui", "player_x", this->geometry().x());
        aud_set_int ("qtui", "player_y", this->geometry().y());
#endif

        audqt::unregister_dock_host();

#4 Updated by John Lindgren about 2 months ago

  • Status changed from New to Closed

I don't think we should add a workaround this ugly for a minor bug that Qt has already fixed. I'm going to close this support ticket. You have a solution already, just update Qt to 5.15.x.

Also available in: Atom PDF