bugGNUstep - Bugs: bug #35294, NSEvent issue

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #35294: NSEvent issue

Submitted by:  Germán Arias <espectador>
Submitted on:  Thu 12 Jan 2012 01:26:35 AM UTC  
 
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Fred Kiefer <FredKiefer>
Open/Closed: Closed

Sat 14 Jan 2012 04:00:11 PM UTC, comment #4:

Great, this means we may close this issue.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Sat 14 Jan 2012 05:00:25 AM UTC, comment #3:

Well, I found the problem here. As far as I discovered today, gnustep uses a key called GSSecondHelpKey that, be default, corresponds with key Super_L (the key with the Windows logo). This is done at line 1928 in file XGServerEvent.m at gnustep-back. So, setting GSSecondHelKey to None solve the problem. I don't knew about these keys, because not appears in SystemPreferences. So this is not a bug, was a conflict between keys. On the other hand, currently SystemPreferences don't allow you set the keys configuration.

Germán Arias <espectador>
Fri 13 Jan 2012 05:05:40 AM UTC, comment #2:

Now the clicks are detected always, independently of GSBackHandlesWindowDecorations value. Thanks.

But the problem with the modifier key is still present, at least in my system. Also independently of GSBackHandlesWindowDecorations value. After do many tests, I found the problem only with left Control key, and only when this modifier key is the left key with the Windows logo. This is not a problem with the keyboard, I tested with two different keyboards. But could be a problem on my system. So here are the steps to reproduce the issue:

1) Launch KeyTest.app and then do many clicks above the window, pressing left Control key randomly. The method -mouseDown: always detects when the Control key is pressed. Do a last click above the window without the Control key (to set the TextField to NO).

2) Do a click above the panel.

3) Press the left Control Key and do many clicks above the window. The method -mouseDown: detects the "Control" key only in the first click.

This problem appears only when you return to the window (after do a click above the panel) and when the left Control key is pressed at first click.

Germán Arias <espectador>
Thu 12 Jan 2012 09:42:17 AM UTC, comment #1:

That is a very interesting problem you found here.

I could not reproduce the issue with GSBackHandlesWindowDecorations set to YES, here things seem to work as expected for me. Perhaps you could give some more details on how to reproduce.

But for GSBackHandlesWindowDecorations set to NO, I am able to reproduce this issue. Some debugging showed the reason for it. When you click on a window the event first gets dispatched to that window. The window sends it on to the view you clicked on. The next step you would expect is that the view that does not impelement any event handling passes that event on and so it does. But not as you may expect to the window, it passes it on to the next responder, which is of course the view containing that view. And for the case where gui handles the window decoration this is the GSStandardWindowDecorationView and this class has mouse down behaviour, so the event gets swallowed here.

I scattered a few calls to the super implementation into that method and things seem to work fine for me now. Please give it a try.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Thu 12 Jan 2012 01:26:35 AM UTC, original submission:

I ran into a weird issue with NSEvent. Attached an app to test this. This app have one window, an instance of the class MyWindow, and a panel. The class MyWindow just implement the method -mouseDown:. This method check if the user has pressed the CONTROL modifier key when does the click. And display the result in a TextField. Also display a log message when the method is called.

With GSBackHandlesWindowDecorations set to NO. Doing click above the window does nothing. You need select the Panel and then do click above the window, the Window gets the event, but only the first click, no the following clicks.

With GSBackHandlesWindowDecorations set to YES. All seems to work OK and all clicks are detected. But if you make a click above the panel, and then a click above the window. The modifier key is detected just in first click. No in the following clicks.

Germán Arias <espectador>

 

Attached Files
file #24803:  KeyTest-0.1.tar.gz added by espectador (3KiB - application/x-gzip - Test app)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by espectador (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 14 Jan 2012 04:00:11 PM UTCFredKieferStatusReady For Test=>Fixed
      Open/ClosedIn Test=>Closed
    Thu 12 Jan 2012 09:42:17 AM UTCFredKieferStatusNone=>Ready For Test
      Assigned toNone=>FredKiefer
      Open/ClosedOpen=>In Test
    Thu 12 Jan 2012 01:26:35 AM UTCespectadorAttached File-=>Added KeyTest-0.1.tar.gz, #24803

    Back to the top


    Powered by Savane 3.1-cleanup1