Typical behavior with the arrow keys and collapsible lists are Left / Right Arrow will open/close the list.
Closed (Left Arrow)
Open (Right Arrow)
Up / Down Arrow moves the selection bar accordingly …
Down one Line (Down Arrow)
All good so far.
Following those actions, if the selection line is in a collapsible list section as shown above, pressing the Left Arrow should return the selection line to the next higher level of the collapsible list.
Using Finder as an example:
If I press Left Arrow with the selection line over
… the selection line will jump up to the next higher level.
Picard does not move the selection line on that Left Arrow input.
In this example I’m looking at the code for album.py, but the same behavior should be throughout the entire application. Does this need to be changed at each level or are there universal UI/keyboard input settings higher up in the source tree?
…and what am I looking for call wise, for intercepting keyboard input?
Like if I also want to add functionality so that Command-Q (CTRL-Q) or ESC can be used at the Quit Picard Dialog?
The keyboard can be used to fully exit from Picard, or ESC if you didn’t mean to enter Command-Q.
I Presume the code for the Quit is
def show_quit_confirmation(self): in
def show_quit_confirmation(self): unsaved_files = sum(a.get_num_unsaved_files() for a in self.tagger.albums.values()) QMessageBox = QtWidgets.QMessageBox if unsaved_files > 0: msg = QMessageBox(self) msg.setIcon(QMessageBox.Question) msg.setWindowModality(QtCore.Qt.WindowModal) msg.setWindowTitle(_("Unsaved Changes")) msg.setText(_("Are you sure you want to quit Picard?")) txt = ngettext( "There is %d unsaved file. Closing Picard will lose all unsaved changes.", "There are %d unsaved files. Closing Picard will lose all unsaved changes.", unsaved_files) % unsaved_files msg.setInformativeText(txt) cancel = msg.addButton(QMessageBox.Cancel) msg.setDefaultButton(cancel) msg.addButton(_("&Quit Picard"), QMessageBox.YesRole) ret = msg.exec_() if ret == QMessageBox.Cancel: return False return True
There (or course) are several ways to process keyboard inputs and do GUI calls… I’m not figuring out which way exactly Picard is doing UI within Python, to follow documentation against.