There are a lot of scenarios where there are eventual https://www.audiotool.com/board/bug_reports-b5kxKt/element_focus_errors (see that article for more information). However, a possibly fairly simple fix would be to change the approach of how element focus is handled. Just to be clear, I’m using “element focus” to mean that controls, shortcuts (see https://www.audiotool.com/board/bug_reports-b5kxKt/timeline_tool_shortcuts ), and other aspects of UI should be modifiable only when their corresponding element (e.g. the Timeline, Desktop, Sidebars, etc.) is in focus. This is already partially the case (where clicking on an element will fix Element Focus Errors). But, by changing focus from being activated from a click to being activated by hovering might solve these issues cleanly.
Disclaimer: Bear in mind, I don’t know how Audiotool is programmed or how these events are handled. I only have a basic knowledge and curiosity and this is only a plausible suggestion.
Comments (5)
Your rationale behind the chat bar problem makes sense, however, I'd suggest that this doesn't need to be a global fix.
Perhaps, most logically implement the hover-to-focus function where it makes most sense: the desktop and the timeline.
Everywhere else can remain the same, where an actually click brings and maintains the focus until otherwise is true.
(This would mean that conditionally, the desktop and timeline would have to be brought into focus by a click as well, but only if a prior element was brought into focus by a click rather than hover...)
Something like that
I was checking focus behaviour in other software and I often see a strict "focus on click" design. For example Writer, a text processor that can open several windows of the same document (analogous to desktop and timeline), all of which accept keyboard shortcuts, maintains focus (typing and shortcuts) on the window that was last clicked on. I think that the solution for Audiotool would be to establish a "hierarchy of focus", like this:
Any element that can be clicked is highlighted on hover, no matter if the area it's in has focus or not.
Text fields are at the top of the hierarchy, never lose focus and any shortcuts that don't use Ctrl or function keys (F1-F12) don't work (they are typed as text in the field).
Clicking the desktop-only or timeline-only layout icons automatically give focus to those areas. This is to avoid keyboard shortcuts from going to a hidden area or not going anywhere at all (for example, if the pointer stays on the top bar).
Clicking the desktop/timeline button enables the "focus on hover" behaviour and is at the bottom of the hierarchy.
Personally, I wouldn't mind single-clicking an empty spot on the desktop or timeline areas to bring the focus there if this would make things easier you.
Just another comment: I see that in a lot of software, keyboard shortcuts always consist on either keystrokes preceded by "Ctrl" or function keys. This removes any ambiguity about which keystrokes should be interpreted as text input and which ones should trigger GUI actions (since Ctrl is a non-printing character). In this way, you could trigger an action of the interface in the middle of typing text in a text field, no mater where the focus is.
I also would go for 1) I think it's the easiest and clearest.
OK, this is pretty obscure, but if you have the wish and the time, there are some documents that explain, among many other things, the standards of how different window systems manage input focus and its transfer between windows and areas. One standard is ICCCM (Inter-Client Communication Conventions Manual) and another, newer and more robust is EWMH (Extended Window Manager Hints) You can find information here: https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints. The official website of the second is here: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html. Just search in page for "input focus" or just "focus".