Bug 266345

Summary: Qt feature to drag window by dragging useless space is awfully irritating.
Product: [Applications] kpat Reporter: Peterson Silva <peterson.235>
Component: generalAssignee: Stephan Kulow <coolo>
Status: RESOLVED DUPLICATE    
Severity: minor CC: cfeck, coates, kde-games-bugs
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Peterson Silva 2011-02-15 02:02:27 UTC 
Version:           unspecified (using KDE 4.6.0) 
OS:                Linux

Go play any KPat game (I guess this applies to everything, although I only play klondike, spider and freecell).

I play fast. I mean, I see an opportunity, I ride my mouse like a crazy horse, go to the card and try to move it as fast as possible.

Many kind-of-addicted gamers know what I'm talking about.

Even when I play patiently this happens.

So let's go to what happens.

A few version numbers ago Qt introduced the wonderful ability to drag windows using that space not used by anything. The thing is this is a very bad feature to have if you're playing Kpat. When you're fullscreen, if you miss a card by one or two pixels, you don't play, the screen unmaximizes and your mouse keeps making it float. then you have to push it over to the top (if you're using the aero snap thingy), and then try to move again.

KSquares is also affected, for that matter.

So I think we should not have this feature for KDE games.

Reproducible: Always

Steps to Reproduce:
Try to play fast. Or even patiently (but play for a longer time, then)

Actual Results:  
A mess. The window moves, you feel frustrated and irritated, you even try to blackmail it: "I'm going back to Aisleriot!". It never works.

Expected Results:  
Don't drag the window. Just do not move the card either.
Comment 1 Parker Coates 2011-02-15 03:12:53 UTC 

*** This bug has been marked as a duplicate of bug 245807 ***
Comment 2 Christoph Feck 2011-02-15 15:48:59 UTC 
Reading the bug report, there should be a "dead zone", where clicks are not passed through to the window dragging code.

Pseudeo code:

void Canvas::mouseEvent(Event e) {
    foreach (Card card, cards) {
        if (card.bounds.contains(e.mouse)) {
            card.clicked()
            e.accept()
            return
        }
    }
    foreach (Card card, cards) {
        if (card.bounds.exanded(-10, -10, 10, 10).contains(e.mouse)) {
            e.accept()
            return
        }
    }
    e.passToOxygen()
}
Comment 3 Christoph Feck 2011-02-15 15:54:57 UTC 
Additional note:

There is no hover feedback or no mouse-over cursor change (not that there should be any, unless it is fast), which means the only user-feedback is the (unexpected) window move/restore.
Comment 4 Christoph Feck 2011-04-23 18:59:12 UTC 
Parker, would you accept a patch fixing this issue?
Comment 5 Parker Coates 2011-04-25 18:19:51 UTC 
(In reply to comment #4)
> Parker, would you accept a patch fixing this issue?

Honestly, I'm hesitant to. When this feature first landed in Oxygen, it brought to light 2 or 3 errors in KPat's mouse event handling (not accept()ing events or failing to call the base class handlers). As I result, I reworked the code to make it "correct".

To add a workaround to KPat for a specific widget-style, especially one as complicated as computing offset areas for each card, strikes me as too much. As far as I know, push buttons and line edits aren't given such "drag buffers".

I guess I'd accept a patch to KCardScene or KPat/View that just disables this dragging completely by accepting all press events, provided it was properly commented and explained why the code was doing "the wrong thing" with the mouse events.
Comment 6 Parker Coates 2011-04-25 18:24:52 UTC 
(In reply to comment #3)
> There is no hover feedback or no mouse-over cursor change (not that there
> should be any, unless it is fast), which means the only user-feedback is the
> (unexpected) window move/restore.

Is this not the case for any QWidget?