Dorico has a massive number of key commands (that’s a good thing), and some of the tools’ tooltips (mouseover text) show the equivalent key command, but many do not, and that IMHO is a bug. Should be easy enough to fix…
Just two examples: Barlines and Repeats. Hovering the mouse over shows the name of the function and clicking brings up the GUI for the function, but the mouse-over tooltip does not show the key command for the function’s pop-over, which is what I really want.
There’s inconsistency within tool groups, too, e.g., the Play button in the Transport panel doesn’t show the key command.
The icons in the right panel don’t have key tips because the buttons and shortcuts aren’t analogous: clicking the button in the right panel opens and closes the panel, whereas typing Shift-B or Shift-R invokes the Bars/Barlines or Repeats popover.
Incidentally, suggesting that something “should be easy to fix” is pretty much the quickest way to irritate any developer.
Just as an aside, the iPad version now has a popup chooser which you can toggle on the right navigation pane. There’s no reason to think this won’t appear in Dorico 4, presumably with key tips to help you learn the popover shortcuts…
thanks, Ed - you read my mind!
Hey Leo - Methinks depends on the developer and the nature of the bug report, but i’ve been a professional computer scientist & sw engineer for almost 40 years and processing bug reports & feature requests are de rigueur - and almost always the submitter has an opinion along the lines of, “How hard can it be?” Usually that doesn’t rise to the level of PITA unless it’s the Marketing folks insisting that some major new feature be added to the product version you’re almost ready to release. Or similarly, insisting that “It can’t possibly take that long” to do the work - and then pressuring Engineering senior management (or worse, the CEO) for your team to do it in half the time you said it would take (and, engineers being engineers - myself included - are already over-optimistic about the schedule by a factor of 2 or more, anyway! (Ask me how I know
So believe when I say I meant no disrespect to the obviously highly-competent Dorico team here. I certainly don’t know their code and perhaps there are some barriers you and I cannot see that prevent something from being fixed or implemented - like the Apple Pencil “Scribble” support, which needs to be implemented in the Qt framework first.
But in this case, I didn’t think it unreasonable to surmise that if some tooltips already have the key commands in their resource text, it would not take a large, complex effort to add it to the ones where it is missing. In the trivial case, that would just be a matter of adding text to the display string. In Dorico, however, users can redefine key commands and also assign MIDI commands. That, plus the fact that, like any modern app, Dorico supports many languages (aka “localization”) means that the tooltip text that gets displayed on mouseover events comes from a lookup table of these strings, aka “resources.” Adding localization to a legacy app is a huge PITA, if not rocket science, but adding more entries in the lookup table should truly be “no big deal.”
Of course, there is always the matter of testing & validation and perhaps user documentation (which is also localized), so without a doubt there is work required, even for the most trivial thing. But in the pantheon of such things, I stand by my guesstimate that the matter of missing key command text in tooltips “should be easy to fix.”
By that, Ed, I mean, “Yes, please!” to adding the popup choose in the right Nav pane.
The Dorico team must love the fact that the derivative iPad project is now feeding features back into the desktop app!
Er, not derivative (the code base is very similar) - also as has been discussed elsewhere in this forum, the iPad version is ahead of the desktop version in terms of UI, and also some features which weren’t, ahem, meant to be in it. Dan Spreadbury has acknowledged that a lot of these things will be appearing in the delayed Dorico 4 release but that the iPad version should be considered somewhere between 3.5 and 4.
I.e it’s likely the relationship is more the other way round, at least for this version. Some of the touch features are likely to feedback into touch enabled desktop computers though.
Thanks for catching me up - Great stuff in both versions, which I’m learning at the same time.
Yeah, I wasnt happy with the word “derivative.” I simply meant that the desktop version existed first and the iPad version started with that codebase. From the blog about the iPad app’s development I understand they were able to use much more of the desktop version than just the core function libraries, in part thanks to the Qt framework - choosing a cross-platform framework to build atop is always difficult, complex, and risky; sounds like their choice of Qt for Dorico at the start of desktop dev was an inspired one!
Even still, in my experience, maintaining cross-platform code is especially complex and tricky business, to say the least, so hats off to the Dorico team. Great stuff so far; may it long continue!
Key commands are added to tool tips automatically for buttons in Dorico’s user interface (or at least for most of them; now that we are using both the older Qt Widgets APIs and the newer Qt Quick/QML APIs, it’s not universal, since it’s only implemented for our Qt Widgets buttons), but only where the underlying command represented by the button has a key command associated. In the case of the buttons in the right-hand notations toolbox in Write mode, those buttons hide and show their corresponding panels, and they don’t have shortcuts by default. Popovers are totally separate commands. If you were to assign a shortcut to the Write > Panels entry for a given panel, then you would see the shortcut in the corresponding button in the right-hand panel.
So, as Leo said in his original reply in this thread, you will get the shortcut in the tool tip if the button corresponds to a command with a shortcut. If it doesn’t, you won’t.