Events are not posted to a particular instance of an event loop object. They are posted to a thread. An event loop object does not "own" any events. It's basically a while loop that calls processEvents of a per thread event dispatcher.

That being said if you nest event loops they all process the same pile of events. It's just that only the top one gets to do it while the calling ones wait for it to return.

Unfortunately, it doesn't seems to work... actions() returns me an empty list.

I think I'll go for QTextEdit::createMimeDataFromSelection() because otherwise I won't be able to deal with drag & drop (I didn't think about it :/ )

Thanks anyway!

@etiennedm Why don't you just use layouts?

@AnkurSharma

But, I also expect that when I am resetting the attribute of WA_InputMethodEvent my widget should no more get the input method events anymore, and thats how it works on Qt on OSX.

I don't know how it works on OSX, I can say for sure though that QObject::eventFilter is executed before the QObject::event method (this is documented) and since you're not giving Qt leeway to process the event as it ordinarily would in the overriden QWidget::event method (you stop the event propagation when you return true from the event filter) you shouldn't expect it to respect the widget attribute. That's what I'm claiming. You should move your code from the eventFilter method to a QWidget::inputMethodEvent override.

I figured it out. You can't call the connect statement for the doubleClick signal until the QListView is in scope.

Hi,

You can modify GUI elements from other threads. You should rather use signals and slots to communicate between both. It will handle the communication properly for you.

IIRC Qt 5.5.0 has a bug handling certain key combination which should be fixed for 5.5.1 If you can, try with this one (you may have to built it by hand though)

@SGaist Fixed it ;)

Then you should either check the code where they do that and integrated it to your project or add the image saving feature to GammaRay