GNOME Bugzilla – Bug 634647
Banshee's search field doesn't respond predictably to Ctrl+a
Last modified: 2011-06-28 12:25:21 UTC
Steps: 1. Open Banshee 2. Click on the search field to focus it 3. Type some characters that return no results 4. Press ctrl+a to select everything in the search field 5. Noticing that nothing happens, ensure that the search field is focused and try again 6. Still no luck This seemed like a straightforward bug until I tried: 1. Open Banshee 2. Click on the search field to focus it 3. Type some characters that return results 4. Press ctrl-a, expecting to select the text in the search field, which has focus. Instead all of the tracks that match the search are selected. 5. Press ctrl-a again, just for kicks. At this point, the text in the search field is finally selected. I'm guessing this was intentional, to make it easier to select all tracks after performing a search, but in my opinion, this is not very intuitive. I expect the shortcut to apply to the field with focus. The problem is even worse when the search returns no results. It seems logical at that point to select your text so you can try another search, but the shortcut doesn't work at all in that scenario.
*** Bug 638981 has been marked as a duplicate of this bug. ***
*** Bug 641769 has been marked as a duplicate of this bug. ***
Created attachment 185570 [details] [review] Allows Ctrl-A to select text in SearchEntry box Banshee's OnKeyPressEvent function disables all hotkeys if an Entry widget has focus. This hotkey disabling is skipped if the Ctrl key is pressed to allow things like Ctrl-L to continue to work. I added a conditional that only allows that to happen if Ctrl is not hit in combination with 'a'. This way, Ctrl-A can function normally inside an Entry widget.
Review of attachment 185570 [details] [review]: Committed, thanks
*** Bug 648417 has been marked as a duplicate of this bug. ***
*** Bug 653539 has been marked as a duplicate of this bug. ***