I create this topic mainly in order to share my observations and suggestion with dev's.
(In truth, I need to move from a topic read by a blind user - would not be nice to bother him.)
Also, anybody is welcomed to ask related questions and user problems.
crash
keyboard input focus, problems and devel suggestions
Forum rules
This forum is now closed.
For help with current Audacity, please post to the 2.x. board for your operating system.
Please post feedback about the current 2.x version on the 2.x.feedback board.
This forum is now closed.
For help with current Audacity, please post to the 2.x. board for your operating system.
Please post feedback about the current 2.x version on the 2.x.feedback board.
-
crash
keyboard input focus, problems and devel suggestions
{{ Moving to here from http://www.audacityteam.org/forum/viewt ... a&start=30}}
What problem should it help.
- any future problem of the kind
- 1.3.5-unicode: one of the arrow problems:
mouse-click(play) moves 'focus' to the Speed alias Transcription toolbar.
(More precissely it gets trapped there after first one or two Lefttarrows.)
The 'focus' is vissible on the play button (fine dotted frame inside the circle)
The problem is decribed and messed up with other problems on
http://www.audacityteam.org/forum/viewt ... kus#p17748
(Go to first to section "Regarding navigation during playback" addressing a problem of roewen.)
and
http://www.audacityteam.org/forum/viewt ... kus#p17760
Some problems described in the first one are solved (identified) in the second one.
Quote: I think that this fokus is foreign to Audacity. Might it be connected to some recent change (I guess there was some) in the widget version?
- 1.2.6: after R and Ctrl M (labels) keys without modifier do not work and I never got away lest with mouse click
- And it might be usefull. Like: need to quickly start/stop recording when doing, silly me, whatever.
Caveats:
Might introduce new bugs. Uff. (Better to hide as possibility in preferences? On/Off by default?)
Example: When writing label / trackname / whatever:
- what happens to the label ?
- make sure the key do not bypass the trackname dialogue (any dialogue) ...
I considered the caveats when posting.
When I now think whould it should DO, it causes me to give up, or escape to "only escape from this know bug/trap" options.
What should it do - variant A:
Reseting whatever could cause problems. (Sounds nonsense.). Or what caused problem at a point in past. (Does not look to future)
(Plus do what seems useful - see usefull above..)
Minimal would be reseting the widgets (general or just the focus staff) and do with labels as in variant B.
What should it do - variant B:
- I do not know. Every peace of code dealing with keyboard directly OR indirectly should specify its own requests. I can give only suggestions. I am not a real programmer.
- the main window: should set focus to itself.
- Widgets: buttons toolbars and other elements should release any focus ownership/capture of keyboard.
elements with edditable content: see labels below
elements of window-type or similar (input source selector): close and release focus.
- labels (label names): should cancel current change, or if that would result in empty label, commit current change.
Should release 'pseudo' focus, I guess that means to stop processing windows keyboard messages.
(If that is connected to selection of the track, deselecting the track can be an option, though probably not wise.)
- tool F1...F6 selection: probably remain the same? (or change to F1 or F6?)
- Preferences > Keyboard - if selecting the key: no action?
(if selecting key for THIS function (if selectable at all), selecting the same key is equivalent to noop (is it?)
and selection the other key
Others:
- menu should close all (levels) (or no action globally as with dialogues below ?)
- If there are open dialogues (Save, Export, Plugin dialogues,...), my suggestion currently is: no action at all (globally). However, if the key normally closes the window, it should do that.
- History, Help windows: The last project window should go on top etc.
- .... ?
Mode
By 'Mode' I only meant anythink that I do not understand. Because there are behaviours (in the 1.2.6 label issue)
that I cannot explain by whatever I would call focus (though, thinking now about, so far all could be explained by windows Messages proccessing.)
Example:
1.2.6: Perhaps we have normal mode a label-enterring mode? The second should be escapable.
Infact there seems to be also some do-nothing-or-nothing-visible mode as far as I remember, certainly
there were more possibilities than yes/no on label track.
(Well, when I think about, it can be explained by enter key sellecting/desellecting the label track - should I experiment ?.)
Example:
Then there is normal versus playback mode -- difference for jump commands (arrows, <, >),
but this is not subject to escape (well.... )
And generally I affraid to use the therm focus.
Unless following exactly the deffinitions from documentation of particular widgets/whatever (diffucult for me!), it can cause missunderstanding. We have to be very carefully.
Very happy to talk to you. And I have also other things if there is time and an ear.galeandrews wrote:Thanks for your suggestions to Maurimol. Can you explain more about your above suggestion - what state of focus should Audacity go to, what do you mean by mode, and what particular problem with 1.3.5 would this help?crash wrote:And a suggection to developpers: Could there be a key (Escape?) that would try to
make keyboard focus and mode to some predefined state.
Gale
What problem should it help.
- any future problem of the kind
- 1.3.5-unicode: one of the arrow problems:
mouse-click(play) moves 'focus' to the Speed alias Transcription toolbar.
(More precissely it gets trapped there after first one or two Lefttarrows.)
The 'focus' is vissible on the play button (fine dotted frame inside the circle)
The problem is decribed and messed up with other problems on
http://www.audacityteam.org/forum/viewt ... kus#p17748
(Go to first to section "Regarding navigation during playback" addressing a problem of roewen.)
and
http://www.audacityteam.org/forum/viewt ... kus#p17760
Some problems described in the first one are solved (identified) in the second one.
Quote: I think that this fokus is foreign to Audacity. Might it be connected to some recent change (I guess there was some) in the widget version?
- 1.2.6: after R and Ctrl M (labels) keys without modifier do not work and I never got away lest with mouse click
- And it might be usefull. Like: need to quickly start/stop recording when doing, silly me, whatever.
Caveats:
Might introduce new bugs. Uff. (Better to hide as possibility in preferences? On/Off by default?)
Example: When writing label / trackname / whatever:
- what happens to the label ?
- make sure the key do not bypass the trackname dialogue (any dialogue) ...
I considered the caveats when posting.
When I now think whould it should DO, it causes me to give up, or escape to "only escape from this know bug/trap" options.
What should it do - variant A:
Reseting whatever could cause problems. (Sounds nonsense.). Or what caused problem at a point in past. (Does not look to future)
(Plus do what seems useful - see usefull above..)
Minimal would be reseting the widgets (general or just the focus staff) and do with labels as in variant B.
What should it do - variant B:
- I do not know. Every peace of code dealing with keyboard directly OR indirectly should specify its own requests. I can give only suggestions. I am not a real programmer.
- the main window: should set focus to itself.
- Widgets: buttons toolbars and other elements should release any focus ownership/capture of keyboard.
elements with edditable content: see labels below
elements of window-type or similar (input source selector): close and release focus.
- labels (label names): should cancel current change, or if that would result in empty label, commit current change.
Should release 'pseudo' focus, I guess that means to stop processing windows keyboard messages.
(If that is connected to selection of the track, deselecting the track can be an option, though probably not wise.)
- tool F1...F6 selection: probably remain the same? (or change to F1 or F6?)
- Preferences > Keyboard - if selecting the key: no action?
(if selecting key for THIS function (if selectable at all), selecting the same key is equivalent to noop (is it?)
and selection the other key
Others:
- menu should close all (levels) (or no action globally as with dialogues below ?)
- If there are open dialogues (Save, Export, Plugin dialogues,...), my suggestion currently is: no action at all (globally). However, if the key normally closes the window, it should do that.
- History, Help windows: The last project window should go on top etc.
- .... ?
Mode
By 'Mode' I only meant anythink that I do not understand. Because there are behaviours (in the 1.2.6 label issue)
that I cannot explain by whatever I would call focus (though, thinking now about, so far all could be explained by windows Messages proccessing.)
Example:
1.2.6: Perhaps we have normal mode a label-enterring mode? The second should be escapable.
Infact there seems to be also some do-nothing-or-nothing-visible mode as far as I remember, certainly
there were more possibilities than yes/no on label track.
(Well, when I think about, it can be explained by enter key sellecting/desellecting the label track - should I experiment ?.)
Example:
Then there is normal versus playback mode -- difference for jump commands (arrows, <, >),
but this is not subject to escape (well.... )
And generally I affraid to use the therm focus.
Unless following exactly the deffinitions from documentation of particular widgets/whatever (diffucult for me!), it can cause missunderstanding. We have to be very carefully.