"Johnny Ljunggren" <[EMAIL PROTECTED]> writes: > >> > >> First detach a toolbar and move it somewhere on the screen. Then >> > >> release and select again and try to move left or right. The >> > >> position is locked sideways, but can be moved vertically. > >> > > Then if I hold button 1 down while over the crosshatch I can drag >> > > the window only up or down. >> > > If I instead drag the toolbar with the Fvwm title I can move the >> > > window anywhere but not dock it. > >> I have decorate transient, that's why you see a frame and >> title bar on the image I posted above. Button 1 on the title >> bar moves a window. ... > What do I do to get to the bottom of this? Should I bring this up with > Trolltech? Since it is working in KDE, gnome, mwm and fvwm 2.4.20 it > looks like Fvwm 2.5.x could be the problem, but you never know. > Is there some way to pay one of the Fvwm developers to look at this, or > could you point me to roughly where in the code this is handled?
Ok, no solution yet, but here's a little info: In Fvwm you can set: BugOpts DebugCRMotionMethod which produces some debug output for moves. In this case I see: _cdim: --- not moved 0x9e50cc8 'File' _cdim: --- not moved 0x9e46cb8 'File' _cdim: --- not moved 0x9e46cb8 'File' this is from the Fvwm source file fvwm/events.c At least part of the Qt logic is in file: qt-x11-opensource-src-4.3.5/src/gui/widgets/qtoolbar.cpp QToolBarPrivate::mouseMoveEvent()
