GSoC 2018 - Beginner Mode and Tutorial Creation - Week 2

Posted 6 years ago

This is my weekly update on my Google Summer of Code project. There will be three parts of this blog post: what I did, what had issues, and what is next. Then, I will end it with a question that I need answered for part of the project.

What I did

  • Fix toolbar editing

    • The original toolbar editing worked only for the note input toolbar. I worked on expanding it to include all toolbars that contained multiple actions. Currently, it is a PR that is under review; it can be found here

  • Add preferences to the workspace

    • While there is still more refinement to be done, I have integrated the saving and loading of preferences directly into the workspace. Currently, only the custom workspaces can save the preferences and there is no default preference list (see question of the week).

  • Add menu bar customization to the workspace

    • While there is no UI way to edit the menubar, the menubar is saved to the workspace and can be edited through the XML code. Still remaining, I need to add a default menubar for Basic and Advanced.

What had issues

Since most of this week was just adding functionality, I didn't have many issues besides temporary coding blocks.

What is next

  • Getting my PR merged

    • Hopefully, I can get my PR merged to help fully flesh out the workspace toolbar customization

  • Refining the new functionality

    • I added a bunch of functionality, but it is still rough around the edges. I need to clean it up and make it up to code with MuseScore so that I can submit a PR.

  • Another PR

    • This PR would be for my current branch (located at the bottom of this blog). I don't expect it to be merged, but I at least want it started.

Question for the Week

Above, I mentioned that I added preferences to the workspace. This allows for simple switching between preferences. However, I need to figure out the use cases of users. So, here is my question:

  • How should I handle default preferences?
    • Since Basic and Advanced don't allow for custom preferences saved to their workspaces (at least not outside of the normal preference saving), I need some form of default to go back to when switching to Basic or Advanced. Otherwise, it just uses the last saved preferences which may be something random. Also, it might be desired that preferences are only saved to the workspace upon request so for the most part they are the same.

Thanks,

Joshua Bonn
GitHub: https://github.com/JoshuaBonn1
Current Branch: workspace-expansion

Comments

• May 27, 2018 - 23:32

My suggestion is to have the .mpal file currently used for workspaces (which means palettes only right now) to save info on preferences and toolbars also.

Reply

• May 29, 2018 - 16:23

Nice! I like how this is coming together.

As for your question: I'm still unclear on exactly which preferences are being saved. I've mentioned before I'm a little uncomfortable with the idea that someone might make some change - say, customizing MIDI shortcuts - and then be surprised if those customizations are lost on switching workspaces. I think most preferences probably should be global, but only a few GUI-related ones be attached to the workspace.

To me, addressing that is the first step toward answer the question of how to deal with the basic and advanced. And oh, by the way, one thing that has always bothered me you might also want to consider - some preferences maybe should really be score style settings. See #100486: Make vertical/horizontal scrolling be a score setting, not global preference. This starts to cross over into another potential area we discussed for your project - making workspace settings part of the score, to facilitate tutorials with limited actions. Even if that doesn't get implemented, it could be worth thinking ahead.

FWIW, while your current PR may be mergeable as is (although you'd want to adddress https://github.com/musescore/MuseScore/pull/3689#discussion_r191321158 in some way), I personally wouldn't be in a hurry on that. After all, depending on how things go with other parts of your project, you may end up revisiting this code in some way.

In general, for a project like this, I'd probably try to keep all related work (eg, everything having to do with the workspace changes) in one branch, but have the individual pieces of it in separate commits. That way you can keep building on the code you've written whether it is merged already or not. Others may hav different ideas on this, but hat's how I generally approach it.

Reply