It's possible to designate a key as associated with a NetLogo button. But the key-press will not activate the button unless the keyboard is in the appropriate state. (I'm not sure what to call that state.) For example, when one starts a model, keys do not activate buttons until one clicks the background outside both the view and the command center. (Try Games > Frogger, Minesweeper, etc. in the Models library.) Also, if one types into the command center, one must click outside to re-active the key-button connections.
Is there a way to activate the keyboard-button connections with code -- so that it can be done, e.g., in setup?
No, this isn't under programmatic control, and it's by design that the command center normally has keyboard focus.
As a user, the easiest thing to do is hide the command center (there's even a keyboard shortcut for this) if you aren't using it, then the keyboard focus will be on the widgets.
Related
How to shift focus on the side bar of VSCode programmatically?
Is there any specific command/end-point I can make use of?
I have some custom contributes.viewsContainers, they are not getting over-ridden by another. So is there any way I can have a focus on them manually after completing a certain task?
When we trap the focus inside a modal, should the focus cycle within the modal or should a user be able to reach the outside, like let's say the browser UI?
It's not clear from the official specifications for the web: https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
At least in an example provided by said specifications, it's actually like so, that you are not able to reach anything but focusable elements in the modal: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
This comes with side-effects like breaking the developer tools:
Here's a video for further clarification: https://streamable.com/i4zcsp
Excellent question! My short answer is: It should not allow to tab outside the modal.
Long answer:
Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.
This leads to two things:
Tab and Shift + Tab are trapped. Reaching the last (first) element will move the focus to the other end.
You have „means for moving keyboard focus outside the dialog”. But then, you must close the dialog.
So when you register a key event listener (and handle Esc to close the dialog and restore focus), you should also handle the mentioned Ctrl+L for reaching the URL bar (resp. Awesome Bar) and perhaps Ctrl+K for the search bar.
Find more keyboard shortcuts for
Firefox
Chrome
Chromium
Edge
Opera
Safari
Given the variety, you might want to dismiss the modal on everything that was not handled inside. User tests would give you a hint on what people expect.
Regarding the developer tools: Opening them in another window might do the trick.
You are only responsible for trapping the focus within the content. That is, anything that is HTML. You don't have to worry about the user moving the focus to other interactive elements that are part of the browser itself.
I often have several tabs open in my browser, looking at different websites. If one of those pages happened to have a dialog open that was trapping the keyboard focus, I would not want my focus to be trapped such that I couldn't get my focus on the browser's tab panel and switch to another tab. Nor would I want the focus trapped so that I couldn't get to the browser's main menu (File, Edit, View, etc). Nor would I want the focus trapped so that I couldn't get to the browser's address bar (alt+D or cmd+L).
One minor nuance in your OP. You mentioned the "official spec" for dialogs. There really isn't an "official" spec with regards to a normative language for a dialog. The "WAI-ARIA Authoring Practices" that you refer to is a fantastic resource and should be followed as much as possible, but not following it does not mean you aren't WCAG conformant. Notice in section "1. Introduction", the first thing it says is:
This section is informative.
You can see definitions of informative and normative. In particular:
Content identified as "informative" or "non-normative" is never required for conformance.
I use Decorated = false to make a frameless, borderless window with gtk#. This means adding my own drag logic and events for minimizing and closing the window, fine. However in Windows (at least), the window loses its native minimize/restore/close animations and I'm unable to minimize the window by clicking in the taskbar as you usually can.
Is there a way to have an undecorated window in gtk and still get the native minimize/restore animations or at least being able to minimize it from the taskbar?
I've experienced this as well. It is my understanding (maybe incorrect) that such features are a part of the windowing for the application. With it undecorated they simply don't exist in the taskbar. You might be able to create "Tasks" that are available when you right-click on the taskbar icon, but I have no experience with doing so. I believe those are technically called "JumpLists" or something like that.
When Gtk GUI is started seems that Gtk sets "optimal" focus order to his controls which can be switched (beside usual way) with arrows. Then we can easily move (modify) focus order with "grab" to whatever enabled widget.
In case of GtkEntry, after pressing enter key "activated" event raises where I do validation and then I would like to jump to next control, like I was pressed "down arrow".
For now I transfer focus with "grab" and explicit name of wanted control but I would like to jump to "next" control of gtk's order without referencing it.
Also I transfer focus manually in keypress event of entry but this is also too fixed and unwanted way.
If I woud be able to set focus to "next control" this can make later modification in GUI much simpler.
Is this possible and how?
Thanks.
The PyGTK FAQ has one way to set tab order and two different ways to traverse it. These are likely the same in whatever language you're using.
I'm trying to get a window to cover the whole screen. Its positioning and dimensions is fine but it gets covered by the Gnome panel. To complicate things I have two monitors and this app needs to support people with multiple screens.
WINDOW_TYPE_HINT_SPLASHSCREEN is a good start. It covers both screens but not the panel. It's still there, just behind the panel.
WINDOW_TYPE_HINT_DOCK looked ideal but I need this window to take focus to listen to a keyboard event. _DOCK seems like it purposely ignores keyboard events (which kind of makes sense). Can I force it to take keyboard focus?
Is there some way I can force a hinted window to cover the panel?
There's window.fullscreen() which you can call on a normal "un-hinted" window. I assume this lets the window manager decide whether the window should cover the panel or not.
If you use the WINDOW_TYPE_HINT_MENU, you can give the focus to the window by calling the gtk_window_present() function.
However, I don't know if you will be able to cover the panel.
Another hint: the panel probably change its _NET_WM_STRUT property so that other windows cannot cover it. Maybe you will have to play with this property (or another) in your window.