GNOME Bugzilla – Bug 608879
Type ahead activation without requiring '?' key press
Last modified: 2020-03-17 08:54:20 UTC
Banshee 1.5.3 finally has type-ahead for the artist etc list. The problem with it is that it needs pressing "?" before it kicks in (after focusing the list, which means another click), which is quite counter-productive. "?" is not a first-level key on many keyboards which means you need to press a modifier key first etc... I personally don't use the keyboard to control banshee so having type-ahead kick in directly after focusing the list (without activating it manually first) would rock. Maybe a preference for this?
I agree completely; when I switched to Banshee, type-ahead was one of the features that I really missed. Now that it's here, I don't even use it because it takes more work than hitting 's' and doing a search. While I agree that pressing '?' is counter-intuitive, an eventual fix to this will probably come in the form of a new preference option (as you suggested) which makes this more of an enhancement request than a bug.
I made the title a bit more descriptive so that this report can be easily found in searches: -Type ahead activation +Type ahead activation without requiring '?' key press
*** Bug 611739 has been marked as a duplicate of this bug. ***
From #611739: Gabriel: > guerda: > > Would it work if the commands were deactivated, if one of > > the two controls are focused? > Yeah, that could work. One concern w/ doing that is it could be confusing and > decrease the value of those one-button shortcuts. Would that be too complicated?
(In reply to comment #4) > Would that be too complicated? IMHO, if a user focusses the artist/album lists by mouse he/she is unlikely to expect those "one-button shortcuts" to work, at least your main concern in this case seems to be with finding an artist or album by name and not starting/stopping playback etc. Clicking anywhere else (header, source list, menu) could then take away the focus and re-activate the one-button shortcuts. Make this behaviour optional like "[x] automatic type-ahead in artist and album lists". Maybe even make it the default and see how many users turn it off (banshee metrics!)
Thanks Michael for your attention and your thoughts. I would really appreciate if this behaviour was controlled by the user. I can understand that users are confused if there one-button-shortcuts won't work if they are in the album/artist box.
Created attachment 162300 [details] [review] Enables seraching w/o ? and remaps one key shortcuts to eliminate collisions Here's what have been remapped: "PlaySongAction" "S" -> "<control>S" "PlayAlbumAction" "A" -> "<control>A" "AudiobookSwitchToGrid" "Escape" "AudiobookEdit" "E" -> "<control>E" "AddToPlayQueueAction" "q" -> "<control>q" "CloseAction" "<Control>W" "PodcastAddAction" "<control><shift>F" "PodcastItemMarkOldAction" "y" -> "<control>y" "PodcastItemDownloadAction" "<control><shift>D" "PodcastItemCancelAction" "<control><shift>C" "AudioscrobblerEnableAction" "control>U" "CloseAction" "<Control>W" "BrowserVisibleAction" "<control>B" lets change to "<control>V" "BookmarksAddAction" "<control>D" "ShowEqualizerAction" "<control>E" "FullScreenAction" "F" ->"<control>F" * confilcts with find; lets make "<control><shift>F" and PodcastAddAction to null "SelectAllAction" "<control>A" "SelectNoneAction" "<control><shift>A" "TrackEditorAction" "E" -> "<control>E" * conflicts with ShowEqualizerAction, lets make "<control>K" "RemoveTracksAction" "Delete" "ImportAction" "<control>I" "OpenLocationAction" "<control>L" "QuitAction" "<control>Q" "PlayPauseAction" "space" ->"<control>space" "NextAction" "N" ->"<control>N" * conflicts with NewPlaylistAction; lets change NewPlaylistAction "PreviousAction" "B" ->"<control>B" * conflicts with BrowserVisibleAction lets change BrowserVisibleAction "SeekToAction" "T" ->"<control>T" "JumpToPlayingTrackAction" "<control>J" "RestartSongAction" "R" ->"<control>R" "StopWhenFinishedAction" "<Shift>space" "NewPlaylistAction" "<control>N" lets change to "<control>P" "RenameSourceAction" "F2" "UnmapSourceAction" "<shift>Delete" "OpenSourceSwitcher" "G" ->"<control>G"
(In reply to comment #7) > "PlayAlbumAction" "A" > -> "<control>A" Conflicts with "select all". > "AddToPlayQueueAction" "q" > -> "<control>q" Ctrl+q is already used for quitting the application. > "PlayPauseAction" "space" > ->"<control>space" Why not let it be "space" (maybe in addition to ctrl+space)? Space usually never starts a type-ahead find. > "NextAction" "N" > ->"<control>N" * > conflicts with NewPlaylistAction; lets change NewPlaylistAction How about the right arrow key? It's not used at the moment and it's a natural choice. > "PreviousAction" "B" > ->"<control>B" * > conflicts with BrowserVisibleAction lets change BrowserVisibleAction How about left arrow key?
Created attachment 162316 [details] [review] resolves conflicts created by prev feature patch >> "PlayAlbumAction" "A" >> -> "<control>A" > >Conflicts with "select all". "PlayAlbumAction" "A" -> "<control>m" > >> "AddToPlayQueueAction" "q" >> -> "<control>q" > >Ctrl+q is already used for quitting the application. "AddToPlayQueueAction" "q" -> "<shift>q" > >> "PlayPauseAction" "space" >> ->"<control>space" > >Why not let it be "space" (maybe in addition to ctrl+space)? Space usually >never starts a type-ahead find. "PlayPauseAction" "space" space works fine; it doesnt start/stop playback when you searching list and hit space > >> "NextAction" "N" >> ->"<control>N" * >> conflicts with NewPlaylistAction; lets change NewPlaylistAction > >How about the right arrow key? It's not used at the moment and it's a natural >choice. > >> "PreviousAction" "B" >> ->"<control>B" * >> conflicts with BrowserVisibleAction lets change BrowserVisibleAction > >How about left arrow key? "NextAction" "N" ->"<control>Right" "PreviousAction" "B" ->"<control>Left" ================================================================================ I'll paste all shortcuts here again was become "PlaySongAction" "S" -> "<control>S" "PlayAlbumAction" "A" -> "<control>m" "AudiobookSwitchToGrid" "Escape" "AudiobookEdit" "E" -> "<control>E" "AddToPlayQueueAction" "q" -> "<shift>q" "CloseAction" "<Control>W" "PodcastAddAction" "<control><shift>F" -> null "PodcastItemMarkOldAction" "y" -> "<control>y" "PodcastItemDownloadAction" "<control><shift>D" "PodcastItemCancelAction" "<control><shift>C" "AudioscrobblerEnableAction" "control>U" "CloseAction" "<Control>W" "BrowserVisibleAction" "<control>B" "BookmarksAddAction" "<control>D" "ShowEqualizerAction" "<control>E" "FullScreenAction" "F" ->"<control><shift>F" * "SelectAllAction" "<control>A" "SelectNoneAction" "<control><shift>A" "TrackEditorAction" "E" -> "<control>K" "RemoveTracksAction" "Delete" "ImportAction" "<control>I" "OpenLocationAction" "<control>L" "QuitAction" "<control>Q" "PlayPauseAction" "space" "NextAction" "N" ->"<control>Right" "PreviousAction" "B" ->"<control>Left" "SeekToAction" "T" ->"<control>T" "JumpToPlayingTrackAction" "<control>J" "RestartSongAction" "R" ->"<control>R" "StopWhenFinishedAction" "<Shift>space" "NewPlaylistAction" "<control>N" "RenameSourceAction" "F2" "UnmapSourceAction" "<shift>Delete" "OpenSourceSwitcher" "G" ->"<control>G"
Dmitry, thanks so much for working on this! A couple things: - Using the nereid client, the unmodified 's' shortcut still focuses on the search field. It's my personal opinion that this shortcut can be removed completely, since F3, '/', and <control>F all do the exact same thing. - Changing "F" for fullscreen to <control><shift>F might not be worth it since this is not very discoverable, and F11 does the same thing (and is used in many other applications). -I agree with Robin that space bar doesn't need a modifier, since it should never need to start a type-ahead search. Also, I really like the idea of arrow keys replacing <control>N and <control>B, but you may want to add a <control> modifier to the arrow keys. See Bug 535924 for more discussion on that. -This is just speculation, but I doubt a patch that completely changes the current behavior will be accepted. This would be much more likely to go through if it was implemented as a preference option. But for those of us who want this behavior and don't mind running a patched Banshee, this is awesome! Thanks again.
I guess I was typing my comment as you were updating the patch, so some things might be irrelevant now. I'll check back in after I've tested the new patch.
One quick thing, though, could you make your latest patch a cumulative patch that doesn't depend on the first one? It will be easier for others who might want to test this if they can just apply one patch, rather than a succession of patches.
(In reply to comment #10) > Also, I really like the idea of arrow keys replacing <control>N and > <control>B, but you may want to add a <control> modifier to the arrow keys. The most convenient behaviour would be to have ctrl+arrow keys work everywhere; and when the focus is on the track list, pressing ctrl shouldn't be necessary to switch tracks.
Created attachment 162329 [details] [review] cumulitive patch 1st+2nd
Created attachment 162720 [details] [review] Type ahead activation without requiring '?' key press
4th patch is cumulitive for 1.7.1 It partly applies to 1.6.1 (In reply to comment #10) > Dmitry, thanks so much for working on this! A couple things: > > - Using the nereid client, the unmodified 's' shortcut still focuses on the > search field. It's my personal opinion that this shortcut can be removed > completely, since F3, '/', and <control>F all do the exact same thing. Done in 4th patch > - Changing "F" for fullscreen to <control><shift>F might not be worth it since > this is not very discoverable, and F11 does the same thing (and is used in many > other applications). F11 for fullscreen already there
What is needed here? Just review?
(In reply to comment #17) > What is needed here? Just review? IIRC, the patch changes the default behavior but doesn't (yet) include a preference option to toggle the new behavior on and off -- this would probably be needed for the patch to be considered for inclusion. Additionally, I don't think the patch applies to master any more. Also, with this patch applied, starting a type-ahead search with the 'c' key tended to crash Banshee.
+1 I would also love this functionality. I personally do not use/desire any other keyboard shortcuts.
*** Bug 645111 has been marked as a duplicate of this bug. ***
Hello Banshee community! I recently tried to use Banshee. Ubuntu is planning to replace the old-fashioned Rythmbox with Banshee, so i also thought i give it a try. But it is nearly impossible for a new banshee-user to find out that pressing "?" activates the type-ahead feature. It's not intuitive, and it hasn't been mentioned in the Banshee Help. It would be much easier for newcomers like me, if banshee uses the same short-cuts as other GNOME Apps like Totem, or Rythmbox. For example: Play/Pause: <Space> Next Track: <Alt> + <Right Key> Previous Track: <Alt> + <Left Key> Fullscreen: <F11> and sometimes <Ctrl> + <Enter> Edit Properties: <Alt>+<Enter> The only single-letter-shortcut in Banshee 1.9.5 i have found without an equivalent is <Y> to mark a Podcast as old. I would map this to <Ctrl> + <o> like _o_ld. But im afraid that old banshee-users will get angry if we kill they're known shortcuts. So a newer Banshee needs a "restore single-letter-shortcuts" option. I hope my opinion will help you to improve the usability of this great program a little bit.
*** Bug 648939 has been marked as a duplicate of this bug. ***
Review of attachment 162720 [details] [review]: Please see my comment 18. With this patch applied, starting a type-ahead search with the 'C' key crashes Banshee, and the patch no longer applies cleanly to git master. Also, I highly doubt this functionality will be included unless there is also a preference option to switch between this behavior and the traditional keyboard shortcuts.
*** Bug 659542 has been marked as a duplicate of this bug. ***
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.