MuseScore icon indicating copy to clipboard operation
MuseScore copied to clipboard

[MU4 Issue] Palette search command should open palette if not already visible

Open MarcSabatella opened this issue 3 years ago • 2 comments

Describe the bug Ctrl+F9 is the palette search command, and it should work whether the palette is currently open or not

To Reproduce Steps to reproduce the behavior:

  1. Make sure palette is open
  2. Press Ctrl+F9
  3. Note focus moves (eventually) to the search box
  4. Close palette
  5. Press Ctrl+F9 again
  6. See error - palette is not reopened; nothing happens

Expected behavior Ctrl+F9 should open the palette first if not already open, then move focus there.

Platform information

  • OS: Linux

Additional context This is especially important for accessibility - the palette search command is the primary way many blind users interface with the palettes. This worked as expected in MU3.

MarcSabatella avatar Aug 15 '22 18:08 MarcSabatella

The "eventually" part in the description above is a reference to https://github.com/musescore/MuseScore/issues/12753. The two issues are of course not related, but I'm guessing both will involve working on the same area of code, so it might make sense to tackle them together, or at least coordinate efforts.

MarcSabatella avatar Aug 15 '22 18:08 MarcSabatella

Same, BTW, if the palettes panel is open but isn't currently active in the side - like if you had been using the instruments or properties panel more recently

@Tantacrul this is pretty important for accessibility, as it renders the palette much more difficult to get to for blind users than it was in MU3

MarcSabatella avatar Sep 23 '22 03:09 MarcSabatella

P.S. a quick glance at the code:

PaletteRootModel::PaletteRootModel(QObject* parent)
     : QObject(parent)
 {
     dispatcher()->reg(this, "palette-search", [this]() {
         emit paletteSearchRequested();

Doesn't seem to have any access to dockwidgets or whatever it is that the Palette panel is in order to check its status. And handling of onPaletteSearchRequested in the QML doesn't seem to have access to that either (but maybe it does?). The way this is tightly knit makes it seem difficult, but again I'm new to MS4. In MS3 you could just take the command "palette-search" and find the function and see that it had access to the function to check the visibility of the dock and perform a "raise" or what have you. I wonder if this can be solved soon though with some discussion etc.

worldwideweary avatar Jul 18 '23 21:07 worldwideweary

P.S. FWIW: After rebasing https://github.com/musescore/MuseScore/pull/15675 and squashing (for simplicity's sake) and then simply adding:

dispatcher()->dispatch("dock-set-open", ActionData::make_arg2<QString, bool>("palettesPanel", true));

within:

PaletteRootModel::PaletteRootModel(QObject* parent)
    : QObject(parent)
{
    dispatcher()->reg(this, "palette-search", [this]() {
        dispatcher()->dispatch("dock-set-open", ActionData::make_arg2<QString, bool>("palettesPanel", true));
        emit paletteSearchRequested();
    });

I get the "user desired behavior" as one would expect how MS3 worked. However, I'm not sure this is "Kosher" since I'm using the string literal "palettesPanel" because having a hard time figuring out how to get access to

QString NotationPageModel::palettesPanelName() const; or the DockName PALETTES_PANEL_NAME;

from within paletterootmodel.cpp. Any pointers about how this should be done by a "seasoned team member" would be appreciated. Plus I'm sure this could be done somewhere else or some how else...

worldwideweary avatar Jul 31 '23 22:07 worldwideweary