Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Play/Pause using keyboards shortcuts fails after loading a track due to a focus change introduced in v2.4.0 #13160

Open
sysdbugfactory opened this issue Apr 22, 2024 · 10 comments
Labels

Comments

@sysdbugfactory
Copy link

Bug Description

using the keyboard shortcuts to play/pause a track start a search instead of playing/pausing the track.

To replicate the issue, load a track into a deck by drag'n'drop to either the waveform display or waveform overview, then use the shortcut keys to play/pause. instead of the track playing/pausing, the characters are added to the search box.

I have to click into the waveform display for the shortcuts to work and for some reason every time I alt tab back into mixxx the focus returns into the search box.

After loading a track into a deck I expect the shortcuts to play/pause and not search for another track. This was the behaviour in previous mixxx version.

Version

2.4.0

OS

Linux (manjaro)

@ronso0
Copy link
Member

ronso0 commented Apr 22, 2024

I can not reproduce this. Dragging a track from the library (track view has keyboard focus) to a waveform or overview widget does not steal focus from the library.

Please describe step by step how focus changes, and which waveform type you use (though that should not affect the overview waveform).

@sysdbugfactory
Copy link
Author

sorry it might have been unclear in my bug report that this happens when you drag a file from outside mixxx into mixxx.

here is a quick video demonstrating the issue: mixxx_focus_issue.webm

I hope this explains better the issue.

@ronso0
Copy link
Member

ronso0 commented Apr 23, 2024

Oh okay, understood (without watching the video).
I niticed this, too, though in entirely uncritical situations.
So zhe expectation is basically that none or a non-catching widget has focus when you activate the Mixxx main window via drag'n'drop.

I'll take a look.

@ronso0
Copy link
Member

ronso0 commented Apr 24, 2024

The searchbar gets focus only if no widget had focus before (e.g. when pressing Tab after start)
So basically keyboard shortcuts will work if you had the Mixxx main window active and the tracks view focused before dnd'ing from the OS.

Btw I can't activate the main window with D'n'D, I need to actively activate it with Alt+Tab or by hovering the Mixxx iccon in my taskbar / dock.

I see this has changed with 2.4, so I'll take a look if this can be adjusted somehow.

@sysdbugfactory
Copy link
Author

sysdbugfactory commented Apr 24, 2024

I am not familiar with the technical terms you use here, so allow me to formulate with my own words:

my expectation is that after loading a track into a deck the keyboard shortcut to play/pause will work, regardless of how the track was loaded into the deck.

d'n'd alone does not activate mixxx window, when your desktop is set to click to focus.

It does when your desktop is set to "focus follow mouse".

in "click to focus" mode, you can drag and drop and activate mixxx at the same time.
either first drag and hold the file, then alt-tab to mixxx, and drop the file into the deck.
or alternatively drag the file to mixxx in the taskbar to raise and activate the mixxx window and drop into the deck.

not sure if those use case change anything to what you already said, I suppose they don't, but it's worth mentioning them for testing a solution actually works.

I assume the focus catching widgets you mention are the parts of the UI that get a colored outline when they have focus. the sections of the library: search, browse and track list.

After a round of testing, I can confirm your findings. when the mixxx window is activated and none of those widgets had focus when the mixxx window was deactivated, the focus will be applied to search if it exists, and the browse section if it does not.
IIRC before v2.4.0 mixxx would restore its previous focus state when its window is activated instead of actively trying to give focus to a focusable widget.

during my further testing I was able to trigger this issue simply by interacting with mixxx, it happens every time the main window gets focus back from anywhere:

  1. load a track from library
  2. click on the waveform to move the track a couple bars in (this will remove focus)
  3. open the preferences to check or change a setting
  4. close the preferences
  5. the search bar now has focus and grabs the keyboard preventing the shortcuts from working

you can replace step 3 and 4 with
3. creating a new crate / playlist
4. confirming or cancelling the creation

or
3. clicking the on air button with no streaming server configured
4. closing the error message.

or
3. displaying mixxx about from help menu
4. closing the about window

or
3. double click track name in deck to open track properties editor
4. close track properties editor

or
3. right click on cover art to display it in full
4. close full display of cover art

or
3. use the load track to deck from file menu

or
3. press F12 to show the keywheel
4. press F12 again to hide the keywheel

@ronso0
Copy link
Member

ronso0 commented Apr 24, 2024

My observation regarding activation of the main window was just that, an observation, and is indeed a consequence of desktop config. Just ignore.

the focus catching widgets you mention

I was referingto the searchbar (or some other lineedit like the beat size spinboxes).

@ronso0
Copy link
Member

ronso0 commented Apr 24, 2024

  1. click on the waveform to move the track a couple bars in (this will remove focus)

I think this is the culprit, caused by the new waveform implementation.
IIUC, when the main window gets focus, it somehow assumes the first widget in the (focus) tab order has focus and jumps to the next.

  • in 2.3, 1st was the searchbar, so it jumped to the sidebar
  • in 2.4 it's the waveform viewer (even though that can not be Tab'ed to), so it jumps to the sidebar.

I'll take a look.

@ronso0
Copy link
Member

ronso0 commented Apr 24, 2024

FWIW Spinnies can also be focused since the (waveform-related) refactoring.

@sysdbugfactory
Copy link
Author

thank you for fixing this so fast.

so if I understand what you said, if I click the spinnies instead of the waveform the focus should not jump to search bar and could be used as a workaround until the next release of mixxx ?

@ronso0
Copy link
Member

ronso0 commented Apr 28, 2024

#13173 was not a fix, I experrienced some inconsistencies (which I need to investigate).

#13174 is a workaround that aims to improve the GUI experience.
Re the actual issue (searchbar gets focus) I have no idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants