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

[Hugo Pereira Da Costa]

On Saturday 03 July 2010 23:01:04 Dawit A wrote:
> 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!

There is a (somewhat hidden) option to do the above.
Type oxygen-settings in either konsole and krunner. The option is on the first 
page (Windows' drag mode). 

As for dragging from disabled widgets, this was a feature originally absent 
from the code but then requested by some people. And it actually make sense a 
least programatically since all disabled widgets do pass their mouse 
press/move events to their parents (and ultimately their main window).

Hugo

> 
> 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