On Tue, Nov 03, 2009 at 10:57:00PM -0800, Derek B. Noonburg wrote: > There is some code at the end of HandleClientMessage() that forwards > ClientMessage events on to the client window. It's marked with a > comments that says "I'm not so sure this should be done or not, since > every other window manager I've looked at doesn't." If I comment out > that code, drag-and-drop works perfectly.
Apologies for the delay on this -- I have finally found some time to look into this. > I looked at the Qt source code a little bit. If Qt is going to send an > Xdnd event (XdndLeave, XdndEnter, etc.), and the target is another Qt > widget in the same process, it simply calls its own internal event > handler function instead of calling XSendEvent. When the mouse pointer Because Qt has to implement a lot of things for itself, I can't help but wonder if it has always made life difficult. Ah well, I don't like Qt, so my incentive to care is minimal about the state of Qt. :) > moves over an fvwm window frame, Qt uses XSendEvent to send XdndEnter > and XdndLeave ClientMessages (because it doesn't recognize the window ID > as corresponding to a Qt widget). Fvwm forwards those back to the > application, but now with the window ID of the main window, which Qt > does recognize. My guess is that some reordering happens between the > messages sent via XSendEvent and the messages sent directly to Qt's > internal event handler, and that's what is causing the problems. I used xscope on this to see if this is true. It almost is. ClientMessages are unavoidable, of course -- any XClient can't escape receiving them. If there is more than one event in QT's queue, it gets confused seemingly when it flushes the queue and handles the event -- I suspect this is what you were referring to when you said some "reordering" happens. But unlike yourself, have no time or inclination to look into the QT source to find out. :) > I'm really not sure whether this is a Qt bug or an fvwm bug (and I'm not > entirely sure that my analysis is correct). But, given the comment in > the fvwm code, I'm wondering if it would make sense to remove that code. > (I tried hacking the Qt source code, and failed to make it work.) I've met you half-way. I've added a new command to BugOpts called "QtDragnDropWorkaround" which will surpress the sending of ClientEvent messages to the client. I am not removing the code outright, as this is still useful for other applications. Hope it's useful. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
