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

[Dawit A]

Another corner case is  happens when attempting to slide a disabled slider 
widget. IMHO, that should not cause this feature to be activated because it is 
completely unexpected. Additionally, it feels very unnatural to me that the 
window is resized and moved because of this feature when the window is already 
in maximized mode. 

Anyhow, I would at least like to have a config option (does not have to be a 
GUI) to disable this feature. It is rather annoying to "accidentally" move a 
window when you actually did not mean to!

On Wednesday, June 16, 2010 20:34:31 Hugo Pereira Da Costa wrote:
> 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