This is an odd issue I've been having for some time now, so I figure'd I'd ask! Absolutly non-imparitive, this one.

When I drag a window-frame, wobbly windows works. When I drag GTK apps via window-chrome they wobble. But when I drag Qt-based programs by the chrome, no wobble! VLC Firefox and Chrome also wobble using their respective toolkits. In addition, sometimes Qt programs flicker and jitter wildly when being dragged by the chrome.

I've had several KDE SC versions that I've dirty-upgraded to, and the issue has persisted through them. By the looks of it, the wobbly-window plugin doesn't recognise the Qt-based window dragging event; I beleive this to be a configuration issue, as (by this point) I don't think there's any untouched KDE packages that haven't been replaced. I've also tried disabling/re-enabling the plugin, toggling the settings (atempting to trigure some kind of config update) etc.

The back of my mind is screaming at me to mention I installed oxygen-transparent, but I honestly can't remember if that is what caused it. I have since removed oxygen-transparent... When I did run it before uninstalling it, dragging the chrome on qt-apps triggered NO window transformations (the background in oxygen transparent windows unblurs transformed windows, apparently).

Extra info:
- Kubuntu 12.10
- KDE 4.10 (issue persisted since I think 4.8ish)

Again, looow priority, But thanks for anyone willing to help poke this with a stick!

worst answer ever: works for me. I have wobbly windows activated and it wobbles no matter where I move the window. In fact knowing the code behind it: it should not matter at all.

Define "by the chrome" and "Qt apps"
Wobbling will take place if the dragging is done by the WM, in doubt requested via a NETWM event (such as oxygen and bespin will do when you drag some windows by clicking an empty area) - not otherwise (ie. if the move logics are implemented inside the client process and it basically moves itself)

In general, the client toolkit has no impact on the WM at all, only the way moving/resizing is triggered.

VLC is btw. a Qt application.

luebking wrote:Define "by the chrome" and "Qt apps"
Wobbling will take place if the dragging is done by the WM, in doubt requested via a NETWM event (such as oxygen and bespin will do when you drag some windows by clicking an empty area) - not otherwise (ie. if the move logics are implemented inside the client process and it basically moves itself)

In general, the client toolkit has no impact on the WM at all, only the way moving/resizing is triggered.

VLC is btw. a Qt application.

(Sorry, I meant to include VLC as an application w/ broken dragging - victim of editing)

What I'm getting at is the this issue is toolkit-dependant. Only applications using QT are affected, all other applications work correctly. However QT is triggering a move when dragging, it's not the same method as GTK/Firefox/chrome/etc.

That being said, dragging a QT application with the window frame works fine, just the chrome areas break the effects.

I'm thinking in the back of my mind that maybe some sort of fallback drag-trigger is being called by QT, or that my QT has some configuration somewhere telling it to use some alternate dragging call. Is there a QT-specific configuration file somewhere that could be causing this?

Qt itself does usually not provide the ability to drag from some random location.
This is (to my knowledge) only provided by the bespin and oxygen UI styles (and for certain elements by some applications themselves, but we'll ignore that)

You could try the other (ie. bespin if you're right now running oxygen) and see what happens.

Found it!

Turns out in that there was a hidden setting in the oxygen configuration options labeled "Use window manager to perform windows' drag"; I went in though:

Krunner -> oxygen-settings -> general -> (show advanced configuration options) -> and ckecked "Use window manager to perform windows' drag"

I had never seen it before, even when I had shown the advanced settings. I guess using the actual oxygen-settings program was required to expose absolutly all the options available. I guess other toolkits don't respect that value, which is why other toolkits always worked.