Comment 17 for bug 437378

Revision history for this message
In , Fabounet (fabounet03) wrote :

"Cairo dock is known for compatibility issues"
if you mean the issue that makes all applications having embedded video invisible when the dock is running, that has been proved to be a bug in Qt and is opened for 2 years. ;-)

apart from that, the dock runs fine in KDE (it just lacks a plug-in to access the KDE's VFS), except the flickering. When a window is configured by the app, (using a gdk_move_resize), shoudln't the WM be aware that it's a move+resize, and not a move followed by a resize ? after all, the XWindowChanges attributes contain both the size and position changes.
Currently, it seems that either
 - the dock's window is redrawn by the WM at its new position before it's resized
 - or (more likely) the WM uses the old window's content to draw the newly resized window.
So you see the window at a wrong position for a short time.

The correct way would be to receive 1 configure event so that the app knows its new size and content, and then 1 expose event so that the app redraws itself, and the WM should not redraw the window with the old content until this is done.

Do you think something like this can be achieved ? or do you see any workaround that could be implemented at the app level ?
Because anyway as it is right now, it can be considered as a bug.