{"action":"created","issue":{"url":"https://api.github.com/repos/kivy/kivy/issues/3120","labels_url":"https://api.github.com/repos/kivy/kivy/issues/3120/labels{/name}","comments_url":"https://api.github.com/repos/kivy/kivy/issues/3120/comments","events_url":"https://api.github.com/repos/kivy/kivy/issues/3120/events","html_url":"https://github.com/kivy/kivy/issues/3120","id":60395995,"number":3120,"title":"Keyboard behavior in select_for_key_down elides over pauses, combining keys.","user":{"login":"merriam","id":159998,"avatar_url":"https://avatars.githubusercontent.com/u/159998?v=3","gravatar_id":"","url":"https://api.github.com/users/merriam","html_url":"https://github.com/merriam","followers_url":"https://api.github.com/users/merriam/followers","following_url":"https://api.github.com/users/merriam/following{/other_user}","gists_url":"https://api.github.com/users/merriam/gists{/gist_id}","starred_url":"https://api.github.com/users/merriam/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/merriam/subscriptions","organizations_url":"https://api.github.com/users/merriam/orgs","repos_url":"https://api.github.com/users/merriam/repos","events_url":"https://api.github.com/users/merriam/events{/privacy}","received_events_url":"https://api.github.com/users/merriam/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-03-09T19:25:24Z","updated_at":"2015-03-09T21:31:34Z","closed_at":null,"body":"The design of 'select_for_key_down()' in behaviors.py allows for multiple key strokes to be returned.  For example, running examples/widgets/compound_selection.py, typing \"13\" first sees an input of '1' and then aggregates it for a second input of '13'.   However pausing will randomly reset the typing button, so waiting a few seconds and typing '13' again returns aggregates of '131' and '1313'.   It should have reset and returned '1' and '13' as before.\r\n\r\nThe issue is calling time.clock() instead of time.time().  A fix can be found in https://github.com/merriam/kivy/commit/d735622ad5802d6d42a2a739ab83a7521a34e6d4, an\r\nunmerged PR.\r\n"},"comment":{"url":"https://api.github.com/repos/kivy/kivy/issues/comments/77947441","html_url":"https://github.com/kivy/kivy/issues/3120#issuecomment-77947441","issue_url":"https://api.github.com/repos/kivy/kivy/issues/3120","id":77947441,"user":{"login":"kived","id":1126441,"avatar_url":"https://avatars.githubusercontent.com/u/1126441?v=3","gravatar_id":"","url":"https://api.github.com/users/kived","html_url":"https://github.com/kived","followers_url":"https://api.github.com/users/kived/followers","following_url":"https://api.github.com/users/kived/following{/other_user}","gists_url":"https://api.github.com/users/kived/gists{/gist_id}","starred_url":"https://api.github.com/users/kived/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kived/subscriptions","organizations_url":"https://api.github.com/users/kived/orgs","repos_url":"https://api.github.com/users/kived/repos","events_url":"https://api.github.com/users/kived/events{/privacy}","received_events_url":"https://api.github.com/users/kived/received_events","type":"User","site_admin":false},"created_at":"2015-03-09T21:31:34Z","updated_at":"2015-03-09T21:31:34Z","body":"@merriam 39 of your 53 PRs were merged (and it looks like quite a few of the unmerged ones were closed by yourself). I don't see how that qualifies as intending to reject **any** work you submit. But if you submit a PR which has something like double spaces, which we will want to fix, then you are just creating more work for other people.\r\n\r\nAlso, many things you seem to think are \"nitpicking\" are not at all - like rejecting PRs where you add and remove big files. You do realize that everyone still has to download the big file when you do that, even if you remove it in a later commit? And that file will always be in the repo? Unless that commit is removed in a rebase and the master branch is force pushed (generally a very bad idea), the file will never go away. That's the way git works. Leaving that commit in the repo at all is a disservice to our users, especially ones who are in areas with slow Internet connections.\r\n\r\nIt's also not ok to ask us to merge a PR when you know there is an issue with the PR and just saying \"I'll submit another PR to fix that.\" You could easily push a commit with the fix to the original PR, and then ask us to merge it.\r\n\r\nIt really feels like you're just trying to cause problems at this point."}}