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

Palette shortcut #3252

Closed
wants to merge 1 commit into from
Closed

Conversation

divya-urs
Copy link
Contributor

@divya-urs divya-urs commented Jul 30, 2017

This pull request adds the ability to assign a shortcut to a palette element.
A new dialog (Palette Shortcut Manager) has been added which displays a list of palette elements in the current workspace along with the shortcut assigned to each element. A shortcut can be defined or cleared using the palette shortcut manager. The palette shortcut manager can be accessed from the preferences dialog, or by using a shortcut command.
A shortcut can also be assigned using the palette cell context menu or a shortcut command which adds a shortcut to the currently selected palette element.
Shortcuts are saved, so a shortcut defined in a session can be used in later sessions.

@divya-urs divya-urs changed the title set palette shortcut Palette Shortcut Jul 30, 2017
@divya-urs divya-urs changed the title Palette Shortcut Palette shortcut Jul 30, 2017
}
for (int i = 0; i < preferences.paletteCellList.size(); ++i) {
PaletteCellDescription* d = &preferences.paletteCellList[i];
registerPaletteShortcut(d);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indent...

Copy link
Contributor

@lasconic lasconic Jul 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a work in progress. Please refrain to nitpick for now, since the code will change quite a lot.

@@ -1462,6 +1559,7 @@ void Palette::read(XmlReader& e)
add = false; // action is not valid, don't add it to the palette.
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not needed

@lasconic lasconic added the work in progress not finished work or not addressed review label Jul 30, 2017
@Jojo-Schmitz
Copy link
Contributor

@divya-urs: your last commit broke it, it doesn't compile anymore

@divya-urs
Copy link
Contributor Author

divya-urs commented Aug 22, 2017 via email

@Jojo-Schmitz
Copy link
Contributor

Jojo-Schmitz commented Aug 23, 2017

@divya-urs
Copy link
Contributor Author

Okay, I will check.

@Jojo-Schmitz
Copy link
Contributor

Looks like this added further warnings.

@divya-urs
Copy link
Contributor Author

divya-urs commented Aug 24, 2017 via email

@Jojo-Schmitz
Copy link
Contributor

Ah, so I just missunderstood what that commit was about.

@@ -1526,7 +1526,13 @@ Palette* MuseScore::newFretboardDiagramPalette()

void MuseScore::setAdvancedPalette()
{
mscore->getPaletteBox();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not clear on what is going on with this change (or the similar one in setBasicPalette(). Can you describe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm getting the shortcuts from the palette cells, and then setting those shortcuts in the new palette cells. setAdvancedPalette() and setBasicPalette() get called each time the palettes are redrawn, so the shortcuts need to be preserved by saving them before the palette box is cleared, and then setting the shortcuts in the new palette box.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I believe that makes sense. Previously, there was no state that needed preserving - we could just rebuild these from scratch each time we needed to. Now, we need to at least remember the shortcuts assigned. I guess I was thinking somehow we might be reading/writing these on switch if there had been any customization, and the shortcuts would take care of themselves. Would that also have been a valid approach? Any advantages/disadvantages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would also be valid, but many changes would need to be made to use that approach. There were some problems if the workspace was read each time (palette shortcuts would stop working when the workspace was toggled), so to fix this, the palettes are read only on startup, and after that only the shortcuts are stored. Shortcuts are saved, stored each time the workspace is switched.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks for the feedback. I was wondering if the workspace save/restore would be easier, but if not, just keep it the way it is.

@lasconic lasconic removed the work in progress not finished work or not addressed review label Aug 25, 2017
mscore/menus.cpp Outdated
@@ -1569,8 +1569,10 @@ void MuseScore::setAdvancedPalette()
preferences.paletteCellList.clear();
for (int i = 0; i < shortcuts.size(); i++) {
PaletteCell* cell = cells[i];
if (cell->name == "Show More")
if (cell->name == "Show More") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it is also worth making this a boolean flag in the cell, set when we create it, rather than keying off the name? Or if perhaps something like checking if cell->element == 0?

@MarcSabatella
Copy link
Contributor

There was much to like about this PR - as I recall it did the job as advertised and did so in a fairly clean way. f course, it would need work to update for the new palette implementation, but I actually suspect the amount of work needed would not be huge. The changes to existing files were not the most significant part of this PR, it was the new palette shortcut manager, which would probably still be usable as is.

However, what I also remember is that there was a fair amount of code duplication between the management of shortcuts here and for plugins. The code was modelled after the corresponding plugin code but it was kind of a"TODO" to someday actually refactor it to use a common base class or whatever.

The main differentiator between palette/plugin shortcuts on one hand, and ordinary command shortcuts on the other, is the list of commands is fixed and known at compile time, but plugins and palettes can be added, deleted, etc. We've had any number of bugs come up through mismanagement of plugin shortcuts, it would be good to neither reproduce the already existing bugs (some I guess have been fixed since this PR) nor make it harder to maintain the code in the future.

So I feel this PR is a very good reference for someone wanting to re-implement this, but probably it doesn't make sense to literally start from this branch.

@dmitrio95 dmitrio95 added the archived PRs that have gone stale but could potentially be revived in the future label Mar 11, 2020
@dmitrio95
Copy link
Contributor

Needs actualization for current master

@dmitrio95 dmitrio95 closed this Mar 11, 2020
@MarcSabatella MarcSabatella mentioned this pull request Jun 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archived PRs that have gone stale but could potentially be revived in the future
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants