Oxygen's new window-move feature fatal for KJumpingCube game

[Hugo Pereira Da Costa]

Hello Ian,

Some clarifications to you and others.

So first, the quick summary: this (the bug above) has been fixed in trunk. This 
was an oxygen bug. 

Second: the longer summary: 

Unfortunately defining empty by not "filled by pixmaps" is hard to identify at 
the style level. (ultimately: everything, including the empty window 
background, is filled by pixmaps). 

On the other hand some other widgets look empty but can't be drag from (see: 
the song-list in the right panel of amarok: here you want to be able to select 
multiple tracks by moving the pressed mouse around. So no window drag)

So for this feature to work (in oxygen) one has to find other "definitions" of 
empty: 

the most robust one is: not empty when  "mouse press and move events are eaten 
by a widget -because it does something with it- and not passed to its parent 
(ultimately, the parent QMainWindow)". 

That works in most (say 90%) of the cases, but many apps (and not only 
kjumpingcube) do not respect that: one given widget does something with the 
event (turn the dice in kjumpingcube), but still pass it to its parent. 

No real blame to the applications: they were there first, and Qt does not 
require (in general) that you eat an event when you do something with it 
(although it does, sometimes). 

Note that parker's commit to kjumpingcube just addresses that (so that the bug 
is actually fixed twice)

So I had to find other definitions, for corner cases. One is: "it is not empty 
when the mouse cursor is not the default one" (cause it means that you are  
most likely doing smthing with the mouse), This was supposed to work, was 
working in some cases, but not in the case of kjumpingcube (and others), which 
is the bug I fixed. 

Ok. There are other corner cases (not that many though), like "not empty when 
mouse is used to multiple select stuff, not empty when a drag is in progress, 
etc., and I won't list them all here. 

I think this collection of definitions is now robust enough so that no 
application is broken. A large fraction of apps really are not (well, 
basically all the ones I could test, and all the ones corresponding to bug 
reports I got since this feature is enabled by default. Moreover, in most 
cases the fix was "general" so that it would fix more apps than just the one of 
the bug report. 

If there are still some broken apps on the market, there is a mechanism in 
oxygen to blacklist widgets/apps from configuration file (although I don't like 
it and I believe nobody does. This is just here as a safety belt for new bugs 
that would show up and while waiting for the next release where everything 
should be programatically fixed).

I hope this helps clarifying things,

Hugo