Open brugger1 opened 1 year ago
A use case that I think comes up a lot that is kinda sorta related to this is something that might be considered comparative or differential viz.
A user is trying to see what has changed, what is different maybe between two (or more) views (your example), two (or more) time states, two simulation runs with slightly different input decks, two contour lines, two color tables, etc.
And sometimes the best way to do that is to be able to quickly switch among the interesting cases. We do this in our mouse-over feature on our hosted test suite to identify portions of an image that are different from its baseline. Sometimes we do this by adding a few plots to the VisIt plot window and then doing a selection of the plots that allows user to toggle what is hidden and what is viewed. Then, just hitting that button switches back and fourth.
Its a little like flip-book animation too but often with just a handful of states (often just two but probably no more than may be 5)...and this relates somewhat even then to Cinema kinds of operations (e.g. special effect in the movie Matrix).
So, it might be worth thinking about this in a more general context too to ask if there is something we could think of that might encompass a number of these use cases.
We want to make it easier to move between zoom, navigate, and pick modes. But it might also be nice if we could hold down a key (maybe ctrl
) and then click to do a pick of some kind.
AFAICT, the only window that accepts keyboard accelerator options currently is the main GUI Panel. I don't see any accelerator options in the menu in the Viewer. However, there are actions that are common between these two.
Take deleting a window for example. The GUI Panel has Cmd-Del
acceleration (on macOS) for that. When I try that in the Viewer nothing happens. But, it does delete the active window when done in the GUI Panel.
We have undo and redo view in the Viewer menu but only undu in the View Controls window Advanced tab.
If we're going to have multiple windows accept keyboard accelerator options, I wonder if it would make sense to use the same lead key for all acclerator options of a given window. Ctrl-X
for accleration X
in the GUI where as Cmd-X
for accleration X in the Viewer?
Do all platforms treat each window (GUI, Viewer...becase they are independent processes) as their own "address space" for acclerator keys? If they do, we can potentiall repeat the same accelerator key sequence in each window. However, that might have downsides too...like confusing a data destroying operation with some harmless cosmetic adjustment operation.
Just putting some ChatGPT thoughts here...
Yes, there are conventions and standards for defining accelerator keys (also known as keyboard shortcuts) in graphical user interfaces (GUIs), and they can vary between operating systems like Windows, macOS, and Linux.
On Windows, accelerator keys are typically defined using the Alt
key in combination with another key. This is often indicated in the GUI by underlining a letter in the label of a button, menu item, or other control. For instance, Alt + F
might open the File menu. In Windows development environments like Visual Studio, these are often specified in resource files with an ampersand (&
) preceding the character that serves as the shortcut.
macOS uses a slightly different approach, favoring the Command
key for shortcuts. macOS shortcuts often involve the Command
key combined with a letter, number, or other character (e.g., Command + S
for Save). Unlike Windows, macOS does not usually display these shortcuts with underlined characters but lists them next to their corresponding actions in menus.
Linux GUIs can vary more because of the different environments available (like GNOME, KDE, etc.), but they generally follow similar conventions to Windows with the use of the Alt
key. GNOME and KDE might also use the Ctrl
and Super
(Windows key) for various shortcuts. The specifics can depend on the particular desktop environment and how it is configured.
For applications that are designed to work across different operating systems, developers often have to adjust their shortcut schemes to match the expectations and conventions of each system. This can involve not only using different keys but also avoiding conflicts with system-reserved shortcuts.
Modern GUI frameworks and operating systems often provide ways to customize these shortcuts, both to improve accessibility and to allow users to tailor their environment to their workflow. This flexibility can sometimes lead to deviations from the default shortcuts provided by an application.
Developers creating cross-platform applications typically need to account for these differences and may use GUI frameworks that abstract some of the OS-specific details away, providing a consistent programming interface while adhering to each OS's conventions.
@markcmiller86 you make a good point about shortcuts in the viewer versus the GUI. I didn't think of that before, but I don't know of any shortcuts that work in the viewer. That could be a double-edged sword, because we could pick our favorite shortcuts for the viewer and not worry about them clashing with shortcuts in the GUI, but you could also get into trouble like you said where you mean to do one thing but you have the wrong window selected and wind up doing something catastrophic.
I don't think this issue is very high-priority and is more of a nice-to-have feature. If you feel there are too many things to get done for 3.4.2 I suggest we push this out to the next release.
People frequently do picks and then want to change the view, so it would be great if there were keyboard shortcuts for switching between them.