Qt 4.4.3, ерунда с pos(), господа

[Alex Custov]

Привет. Постестируйте пожалуйста из пакета Qt примеров пример shapedclock. Это часы без оконного заголовка, но которые можно таскать мышкой. Там выясняется, что (по крайней мере у меня) 100% есть баг с pos(). Я добавил туда пару дебуг строк:

Код:

void ShapedClock::mousePressEvent(QMouseEvent *event)
{
    if (event->button() == Qt::LeftButton) {
        dragPosition = event->globalPos() - frameGeometry().topLeft();
        qDebug() << "klik" << dragPosition;
        event->accept();
    }
}

void ShapedClock::mouseMoveEvent(QMouseEvent *event)
{
    if (event->buttons() & Qt::LeftButton) {
        qDebug() << "move" << pos() << event->globalPos() << dragPosition << (event->globalPos() - dragPosition);
        move(event->globalPos() - dragPosition);
        event->accept();
    }
}

Вот что он выводит когда я пытаюсь зацепить мышью окно и подвинуть:

Код:

klik QPoint(639,525)
move QPoint(0,0) QPoint(640,525) QPoint(639,525) QPoint(1,0)

т.е. первоначально pos() == QPoint(0, 0)!, собственно поэтому при первоначальном движении окна эти часы прыгают в верхний левый угол. У кого воспроизводится?

У меня Qt 4.4.3, Debian Lenny.

P.S Если не воспроизводится, поставьте в настройках своего WM чтобы он принудительно центрировал новые окна, и опять потестите. Ввозможно Qt не обновляет pos() после того, как WM принудительно подвинул окно.

[Alex Custov]

Проверил в 3.3.8 - работает без багов, всё ок

добавление
нашёл такое же за 2007 год - https://bugzilla.redhat.com/show_bug.cgi?id=426354 , прикол

[SABROG]

Я так понял этот баг есть только в *nix'ах при включеном центрировании окон?

[Alex Custov]

попробовал разные методы расположения окон в KWin - без разницы, баг есть при любом раскладе.

[SABROG]

В виндах такого нет:

Код:

click QPoint(54,22)
move QPoint(320,308) QPoint(375,330) QPoint(54,22) QPoint(321,308)
move QPoint(321,308) QPoint(376,331) QPoint(54,22) QPoint(322,309)
move QPoint(322,309) QPoint(378,333) QPoint(54,22) QPoint(324,311)
move QPoint(324,311) QPoint(379,333) QPoint(54,22) QPoint(325,311)
move QPoint(325,311) QPoint(380,334) QPoint(54,22) QPoint(326,312)
move QPoint(326,312) QPoint(381,334) QPoint(54,22) QPoint(327,312)
move QPoint(327,312) QPoint(381,335) QPoint(54,22) QPoint(327,313)
move QPoint(327,313) QPoint(382,336) QPoint(54,22) QPoint(328,314)

[lit-uriy]

у меня на виндовозе нет такого эфекта.
(Qt 4.4.3, Win2kSP4)

[Alex Custov]

На винде это хорошо, но мне бы в Linux.

добавление
попробовал openbox вместо kwin - тоже самое. Самое интересное, что самый первый вызов XGetWindowAttributes() в mousePressEvent() отдаёт координаты (0,0), хотя окно находится где-то в середине экрана, явно не в (0,0):

Код:

static bool fix(QWidget *w)
{
    XWindowAttributes attrs;
    XGetWindowAttributes(QX11Info::display(), w->effectiveWinId(), &attrs);

    qDebug() << attrs.x << attrs.y;

    return true;
}


void ShapedClock::mousePressEvent(QMouseEvent *event)
{
    if (event->button() == Qt::LeftButton) {
        static bool b = fix(this);

        dragPosition = event->globalPos() - frameGeometry().topLeft();
        event->accept();
    }
}

[SABROG]

Возможно косяк закрался где-то в самом X-сервере. Даже тут говорится, что не все ладно с ним http://doc.trolltech.com/4.5/geometry.html

[LeNsTR]

klik QPoint(41,92)
move QPoint(1120,0) QPoint(1161,93) QPoint(41,92) QPoint(1120,1)

KDE4.2, Qt4.5, багов нет 

[drsm]

у меня под гномом тоже какая-то ерунда происходит с програмным перемещением QDockWidget во floating mode.
симптомы похожи на https://bugzilla.redhat.com/show_bug.cgi?id=426354
те пока не двинули главное окно, QDockWidget::setGeometry() куда-то нетуда вобще двигает.
также глючит maxmize/restore

[Alex Custov]

там написано что это баг metacity, но у меня он на kwin|openbox воспроизводится на ура.