[Qt-interest] pos() bug

[Alex Custov]

2009/2/21 Dominik Kapusta <d at ayoy.net>:
> Hi,
>
> This seems to be a KDE issue, as in Qt 4.4.3 on MacOS X the pos() behaves
> correctly and returns the centre of the desktop. However, in Kubuntu 8.04
> (afair) with KDE 4.1 the widget is not initially placed in the centre, but
> in the upper left corner ( at QPoint(0,0) ). So then your log shows movement
> starting from QPoint(0,0), but this is totally correct in this case. The
> question is why in KDE 3.5.10 the widget is drawn in the centre of the
> desktop. Maybe that's kwin's feature to enforce every new window's placement
> in the centre of the desktop.
>
> Kwin 4.1 apparently doesn't have this feature, but it does something
> interesting too :)
>
> I added one line at the beginning of paintEvent, so that it reports where it
> thinks the widget is at the moment.
>
> void ShapedClock::paintEvent(QPaintEvent *)
> {
>
>    qDebug() << pos();
>
>    static const QPoint hourHand[3] = {
>        QPoint(7, 8),
>        QPoint(-7, 8),
>        QPoint(0, -40)
>   };
>    (...)
> }
>
> And tried different window layout on my desktop. Take a look at screenshots
> from my virtual machine:
>
> http://skitch.com/ayoy/bfxpa/shapedclock-kde4-01
> http://skitch.com/ayoy/bfxp2/shapedclock-kde4-02
> http://skitch.com/ayoy/bfxp3/shapedclock-kde4-03
>
> It seems that kwin refuses to put the window in its initial position (upper
> left corner, as I said earlier) when it doesn't fit there without
> overlapping other windows. Then kwin places the window where it finds place
> for it, without letting the widget know about it. So when you try to move
> the widget, it jumps to upper left corner, where it thought it was.
>
> Similar thing occurs in KDE 3.5.10, but there kwin doesn't look for a place
> for new window, instead it puts it in the centre. Anyway, our widget still
> isn't informed about it.
>
> I guess these issues could be reported to KDE bugzilla (if they still
> support 3.5 branch and unless they fixed it in KDE 4.2).
>
> Cheers,
> Dominik
>
>
>
>
> On 09-02-20 15:33, "Alex Custov" <alex.custov at gmail.com> wrote:
>
>> Hi.
>>
>> I'm using Debian Lenny and Qt 4.4.3, KDE 3.5.10.
>>
>> I tried to run a "shapedclock" example from Qt package. Qt seems to
>> have one very important bug: it doesn't update window position at
>> first run. Similar bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=426354. I added some debug
>> mesages into the source code as follows:
>>
>> 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();
>>     }
>> }
>>
>> What I got:
>> klik QPoint(639,525)
>> move QPoint(0,0) QPoint(640,525) QPoint(639,525) QPoint(1,0)
>>
>> Initially this window with clock inside is positioned by window
>> manager at the center of the screen, but pos() returns QPoint(0, 0) !
>> That's why in the next moment this window jumps to the left top corner
>> of the screen.
>>
>> Any ideas how to fix it? Thanks.
>>
>> P.S.The bug is not present in Qt 3.3.8.
>>
>> --
>>
>
>
>

Hi, Dominik. I'm using KDE 3.5.10. This bug doesn't depend on KWin. It
is reproduced in openbox too. The window is placed in the center of
the screen (or in any place of the screen, but not in (0,0)), BUT
pos() returns QPoint(0,0)! The most interesting thing is that
XGetWindowAttributes() also returns x=0, y=0. And once again - Qt
3.3.8 doesn't have this bug, pos() works just fine in Qt3 for me.

--