{"shas":[["fa200add60ceba28bb21d680e902884da268152a","bd3c5b7446b225b4f9f242c19d9faf4b42148d4e@member.fsf.org","Fix uic includehint errors","Andrew John Hughes"],["3b748900e488181ebd236bf892b760d392818e25","b5c5550b076ca5e3b0f00f104f523b73456d8824@kde.org","qt-bugs@ issue : 16115\nSee http://lists.kde.org/?t=104388858900001&r=1&w=2\n\nSigned-off-by: Andrew John Hughes <gnu_andrew@member.fsf.org>","Lubos Lunak"],["db420d0f81b68bd2a019e0bd95e883bfca73abff","b5c5550b076ca5e3b0f00f104f523b73456d8824@kde.org","qt-bugs@ issue : 25122\n\n Hello,\n\n for example: Open Konqueror window, showing some files. Start dragging one\n desktop icon. If you press/release Ctrl, there'll be a '+' attached to the\n icon, showing the DND operation. Now, while still doing DND, make the\n Konqueror window active (Alt+Tab with KDE-3.1.2+, hover over its taskbar\n entry, Ctrl+Fn to switch to a different virtual desktop, etc.). As soon as\n the app performing DND is not the active application, and the mouse is not\n moving, pressing/releasing Ctrl doesn't do anything, the state only updates\n when the mouse is moved.\n\n This is caused by the fact that Qt has only pointer grab when doing DND, but\n doesn't have keyboard grab. I actually consider this a good thing, because\n the only keys important for DND are modifiers, and they come together with\n pointer events, and not having keyboard grab allows using keyboard shortcuts\n like Alt+Tab while DND. However, when the mouse is not moved, and only a\n modifier key is pressed/released, the app won't get any mouse event, and\n won't also get the keyboard event.\n\n The attached patch changes Qt to explicitly check the modifiers state using\n XQueryPointer() if there's wasn't recently any mouse/keyboard event, which\n ensures the state is updated even in the situation described above.\n\nSigned-off-by: Andrew John Hughes <gnu_andrew@member.fsf.org>","Lubos Lunak"],["be301ab0e373c0f9a4f1b834abfa78413bc45899","b5c5550b076ca5e3b0f00f104f523b73456d8824@kde.org","Default to setting subtype to plain.\n\nqt-bugs@ issue : 38642\nbugs.kde.org number : 71084\n\nHello,\n\n start Mozilla, go e.g. to http://kde.org, start KWrite (or basically any Qt\napp that accepts text drops), select 'Conquer your Desktop!', and try to\ndrag&drop it onto KWrite. The only text pasted should be 'm'.\n\n I don't know much the related mimetype and encoding stuff, so I'm unsure\nwhose fault this actually is. The text drag is provided as a lot of\ntext/something targets, to list some text/_moz_htmlinfo, text/x-moz-url,\ntext/unicode and similar. The problem is, Kate uses QTextDrag::decode() with\nno subtype specified, probably with the intention that as Kate is a text\neditor, it can accept any text pasted. And since the first target provided by\nmozilla is text/x-moz-url, (which moreover seems to be encoded as 16bit\nunicode), the text dropped is completely wrong. You can easily see all\ntargets provided by Mozilla with see_mime.patch applied.\n\n Solution #1: Say that Kate (any pretty much everybody else expecting text)\nshould say \"plain\" as the subtype. In such case, I suggest you drop the\nQTextDrag::decode() variant with no subtype specified, and stress more the\nfact that not specifying a subtype can result in a lot of rubbish. It's\nsimply too tempting to leave the subtype empty and try to accept anything.\n\n Solution #2: When trying to accept anything, try to get useful data. Which\nmeans either sorting the subtypes available somehow, checking only the ones\nQt knows.\n\n To me, #1 seems to be a better choice, or possibly at least something like\nthe attached QTextDrag patch, which simply always tries first \"plain\" subtype\nif none is specified. With this patch, Mozilla even works (that's irony, of\ncourse, Mozilla still pastes the text/plain text as HTML, but at least now it\npastes something where it's easy to point at the offender).\n\nSigned-off-by: Andrew John Hughes <gnu_andrew@member.fsf.org>","Lubos Lunak"]],"ref":"refs/heads/master","size":4,"head":"be301ab0e373c0f9a4f1b834abfa78413bc45899","push_id":39492784}