search

bryceco / nethack-cocoa

OS X tile port of NetHack-3.6 using the native Cocoa framework
11 stars 4 forks source link

messages view "jumpy" when moving using the arrow keys #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. fill the messages view until it gets a scrollbar
2. move with the arrow keys

What is the expected output? What do you see instead?
Clean scrolling to the bottom like when you move with the other keys, numpad or 
menu.
Moving with the arrow keys lets the scroll view "jump" and sometimes it won't 
scroll all the way to 
the bottom

What version of the product are you using? On what operating system?
0.2 & latest svn

Original issue reported on code.google.com by industri...@gmail.com on 21 Mar 2010 at 6:08

GoogleCodeExporter commented 9 years ago 
Sorry, but I can't figure out what this refers to. I use the arrows keys pretty
heavily and don't see the issue. Maybe Dirk can repro it?

Original comment by bryc...@gmail.com on 23 Mar 2010 at 6:10

GoogleCodeExporter commented 9 years ago 
Yes I can reproduce it. It seems to happen only when moving with cursor keys 
(literally, vi or num work fine). It 
scrolls quickly to the top, then back to where it was, but the new message is 
not shown.

It looks like any cursor key issues a Cmd-Up to the message window, then the 
screen gets refreshed, moving the 
messages back.

Original comment by din...@gmail.com on 23 Mar 2010 at 3:44

GoogleCodeExporter commented 9 years ago 
Reproduced with r91 btw.

Original comment by din...@gmail.com on 23 Mar 2010 at 3:52

GoogleCodeExporter commented 9 years ago 
I still can't repro. Even tried hooking up an external keyboard. Can you put a
breakpoint on "+(int)keyWithKeyEvent:(NSEvent *)keyEvent" in wincocoa.m and see 
what
the keypress is producing?

Original comment by bryc...@gmail.com on 24 Mar 2010 at 2:19

GoogleCodeExporter commented 9 years ago

Original comment by din...@gmail.com on 24 Mar 2010 at 5:48

GoogleCodeExporter commented 9 years ago 
It comes to one of the switches (kVK_*Arrow) and sets the key, works fine.

* Are there any cocoa focus changes by default when a cursor key is queued to a 
view?
* I noticed some extraneous calls to MVC.refreshMessages, but could not 
reproduce

Original comment by din...@gmail.com on 24 Mar 2010 at 7:04

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I added a bunch of instrumentation to try to track this down. This is the 
output I
get for an arrow-up keypress. Please post what you see with the bad behavior.

2010-03-24 22:43:12.212 NetHackCocoa[7099:a0f] MainView performKeyEquivalent:
NSEvent: type=KeyDown loc=(0,874) time=20874.2 flags=0xa00100 win=0x0 
winNum=2227
ctxt=0x1006f chars="" unmodchars="" repeat=0 keyCode=126, char = f700
2010-03-24 22:43:12.213 NetHackCocoa[7099:a0f] MainWindow sendEvent: NSEvent:
type=KeyDown loc=(0,874) time=20874.2 flags=0xa00100 win=0x0 winNum=2227 
ctxt=0x1006f
chars="" unmodchars="" repeat=0 keyCode=126, char = f700
2010-03-24 22:43:12.214 NetHackCocoa[7099:a0f] MainView keyDown: NSEvent:
type=KeyDown loc=(0,874) time=20874.2 flags=0xa00100 win=0x0 winNum=2227 
ctxt=0x1006f
chars="" unmodchars="" repeat=0 keyCode=126, char = f700
2010-03-24 22:43:12.314 NetHackCocoa[7099:a0f] MainWindow sendEvent: NSEvent:
type=KeyUp loc=(0,874) time=20874.3 flags=0xa00100 win=0x0 winNum=2227 
ctxt=0x1006f
chars="" unmodchars="" repeat=0 keyCode=126, char = f700

Original comment by bryc...@gmail.com on 25 Mar 2010 at 5:47

GoogleCodeExporter commented 9 years ago 
I'm getting this for the arrow-up while getting bad behavior (rev 101):

2010-03-25 15:27:00.750 NetHackCocoa[2761:a0f] MainView performKeyEquivalent: 
NSEvent: type=KeyDown loc=(0,594) time=608979.8 
flags=0xa00100 win=0x0 winNum=54543 ctxt=0x17c97 chars="" unmodchars="" 
repeat=0 keyCode=126, char = f700
2010-03-25 15:27:00.751 NetHackCocoa[2761:a0f] MainWindow sendEvent: NSEvent: 
type=KeyDown loc=(0,594) time=608979.8 flags=0xa00100 
win=0x0 winNum=54543 ctxt=0x17c97 chars="" unmodchars="" repeat=0 
keyCode=126, char = f700
2010-03-25 15:27:00.752 NetHackCocoa[2761:a0f] MainView keyDown: NSEvent: 
type=KeyDown loc=(0,594) time=608979.8 flags=0xa00100 win=0x0 
winNum=54543 ctxt=0x17c97 chars="" unmodchars="" repeat=0 keyCode=126, 
char = f700
2010-03-25 15:27:00.838 NetHackCocoa[2761:a0f] MainWindow sendEvent: NSEvent: 
type=KeyUp loc=(0,594) time=608979.9 flags=0xa00100 
win=0x0 winNum=54543 ctxt=0x17c97 chars="" unmodchars="" repeat=0 
keyCode=126, char = f700

Original comment by industri...@gmail.com on 25 Mar 2010 at 2:40

GoogleCodeExporter commented 9 years ago 
That wasn't any help. Can you tell me exactly what your setup is, OS and 
hardware, so
I can make it occur on my system?

Original comment by bryc...@gmail.com on 26 Mar 2010 at 5:52

GoogleCodeExporter commented 9 years ago 
Okay, new approach:
In r103 please put a breakpoint on 
messagesScrollClipviewBoundsDidChangeNotification
in MainWindowController and post the stack. It should get hit every time the 
message
window scrolls. That should show us who is triggering the scrolling to the top 
of the
window.

Original comment by bryc...@gmail.com on 26 Mar 2010 at 8:30

GoogleCodeExporter commented 9 years ago 
On my early 2009 MBP with 10.6.2 and r103:
I tried it with a good filled messages view moving free with the arrow keys  
the method gets called 3 times:
(#1) When reaching the breakpoint the first time the view is still scrolled to 
the bottom. The second time it's 
scrolled all the way up. The third time he scrolls down like 1 line. And after 
resuming from there it scroll's 
back to the bottom (when there are enough lines in the message view he dosn't 
even reach the bottom at all).

Doing the same thing while moving with h,j,k,l the method is only called 2 
times leaving the stack backtrace 
#2.

It get's interesting when i do the same thing walking into a closed door  (and 
therefore create a new 
message). Doing this with the arrow keys calls the method 3 times again. 
Producing the BT #3.
Doing it with h,j,k,l gives me 6 calls (#4).

All stack backtraces are in the attached file

Original comment by industri...@gmail.com on 26 Mar 2010 at 3:57

Attachments:

GoogleCodeExporter commented 9 years ago 
It only occurs if you have "Use smooth scrolling" enabled. That is why I didn't 
see
it. Fix will be forthcoming.

Original comment by bryc...@gmail.com on 27 Mar 2010 at 8:42

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision r104.

Original comment by bryc...@gmail.com on 27 Mar 2010 at 10:13