I know that many requests about adding a keyboard configurator to DPL have been posted. I also now that ready-made code libraries or code example allowing to implement such a feature are probably available. But we’ll probably not see this before long.
Meanwhile, we could benefit from a standard feature of Windows, available for all applications allowing to automatically implement keyboard shortcuts by underlining characters in the label of any menu item. This mechanism works in combination with the Alt key. For those who are not aware of this, it works as follows :
Depress the Alt key
If the menu is already displaying underlined characters, just hit the underlined character corresponding to the command that you want to trigger.
This also works for sub menus.
If the application menu doesn’t show any underlined character, depressing the Alt might make them appear (this is the case in Photoshop for example).
There’s no need to code anything to benefit from this feature. The developer just has to add a “&” character before the character that must be underlined in the menu label and to make the underlining consistent. Easy and automatic (the “&” character itself is never displayed, of course).
Unfortunately, DPL doesn’t use this feature. I suspect this is because the DPL main window is not standard. I already mentioned this in this thread.
Implementing this Windows feature would not only add a touch of comfort to the UI but could also help wait for a keyboard configurator like the one found in Photoshop, Affinity Photo or even Lightroom when Keyboard Tamer is installed.
Joaquin
(Canon EOS R, Win11 (R9-5950X/64GB/RTX3060TI), PL6/VP4)
2
Hi Patrick,
Sounds like a great idea to me, as you say better comfort for the users and not too laborious to implement for DPL programmers. E.g. should be nice for “tagging” to “select” or “refuse” which has no keyboard shortcut as of now.
However I do have a question:
To my understanding only minor set of functions is available via menues/submenues and majority of features lies in palets. Would this work for paletts too?
Also many palet functions come with sliders - I suppose they would still have to be touched via mouse?
This mechanism works in all standard menus and dialog boxes. Standard doesn’t mean “not customized”. So, this should work in any menu or dialog box based on standard Windows UI elements, even if they have been customized by using the “hooks” made available in the Windows programming interface.
Not all UI elements are necessarily based on standard Windows UI elements. Sometimes developers are using libraries of custom UI elements that are completely built from scratch. Given the development resources available at DxO Labs, I would be surprised if they had taken the time to develop their owns. So, there’s a good chance that the DPL UI uses standard UI Elements. However, I’m not sure that the DPL palettes are real dialog boxes.
… Curious : After spying a little, it appears that non floating palettes are not even separate windows. It’s very strange. When using a window spying utility, only 2 “real” windows can be detected : the DPL main window and the viewer (+ the image browser window if it is opened). They don’t have any child window. All the rest appears to be elements spread over the main window surface, not having their own life as window. That’s interesting and could shed some light to the problems currently discussed in the threads related to the DPL UI design.
I recommend to those having a window spying utility (WinSpy, WinSpy++ or Window Detective) and knowing how to use it, to look at the DPL window tree and also to the Lightroom window tree to compare. You’ll be surprised.
After investigating a little more, it appears that the DPL UI is designed using XAML (that is, using the WPF technology). I won’t go into technical details that would be annoying for non developers but it’s somehow like if the UI was described in a markup language like HTML and then compiled. This design approach is very different from the “classical UI” development approach. It has its advantages and also its drawbacks.
Anyway, with such an UI, one cannot expect a behavior similar to a “standard” UI. I’m afraid the usual Alt+underlined char. feature cannot be implemented in that case.