I have a Vala Gtk3 app in which exists a treeview widget displaying a tree of data on each tab of a notebook widget. To handle deleting the selected node from the "working" tree, there's a delete action having the [Del] key as its accelerator. Now if the user selects a treeview node and presses the [Del] key, it works as expected; however, there's a search entry widget contained on the app's header bar and if the user selects text in it to delete and then presses the [Del] key, rather than the text being deleted, the app acts like the user intends to delete the selected tree node instead. Clearly, I'm not handling this correctly. What would be the correct way to go about this? Do I need to check in my on_delete() handler for which widget has focus? This seems wrong given that a Gtk.Entry widget would normally handle deletion of text automatically.
Related
The material ui autocomplete is working very nicely for me. I have just one question: when the user presses the enter key on the keyboard, it selects the appropriate entry in the list as expected. Is there a way to move on to the next form element automatically?
I've created a GtkComboBoxText using gtk_combo_box_text_new_with_entry. When I type into it, the "changed" callback is called for every letter.
How can I tell when the user has finished their entry?
I'd be happy to require the user to press 'Enter' at the end, but that doesn't call the callback.
(I'm using GTK+2.)
(Stackoverflow suggested another Q&A which put me on the path to enlightenment. I hadn't seen it while searching before I wrote my Q.)
It boils down to
g_signal_connect(gtk_bin_get_child(GTK_BIN(cb))/*entry*/, "activate", G_CALLBACK(entryActivated), NULL); where cb is the GtkComboBoxText (GtkWidget*). The callback is called when 'Enter' is pressed.
Pressing enter in a GtkComboBoxText that has an entry causes the child GtkEntry to emit the activate signal.
If the GtkComboBoxText contains an entry (via the 'has-entry' property), its contents can be retrieved using gtk_combo_box_text_get_active_text(). The entry itself can be accessed by calling gtk_bin_get_child() on the combo box.
https://developer.gnome.org/gtk2/stable/GtkEntry.html#GtkEntry-activate
The combo box might be considered as part of a form that has its own apply button.
You can also connect to GtkWidget signals. I can't say which event but there is one that is emitted when a widget loses keyboard focus to another widget in the same window. This would allow save on tab out. This is distinct from the window losing focus to another window which is a signal emitted on the GtkWindow. As the widget that has focus in the window does not change when a window loses focus.
After looking at the documentation, I'm able to persist state in the following two cases:
When a WebviewPanel is hidden (ie, the user switches tabs) using getState/setState
When the user restarts the VS Code by implementing a WebviewPanelSerializer
However, I don't see a way to persist state when the panel is destroyed (ie, the user closes it or calls dispose). Here's my scenario:
I execute a command to show the WebviewPanel
I have an input box in the HTML content. I type some string in and press a button to save it. Upon saving, I save it using setState and then append a div with the entered text into the webview.
I close the panel and execute the command again. The panel does not have the appended div.
You have 2 options:
Recreate the additional div when you find saved state (e.g. the input from the user).
Use retainContextWhenHidden to keep the content of the webview, even if it is moved to the background.
The latter won't help when the user closed the webview, however, and is much more resource hungry than the state save/restore operation.
I want to know if there is any way to navigate Dialog components by pressing the Enter Key in the same manner natively implemented by the TAB key?
Though I haven't tried it by handling the keyDown and keyUp events certainly it seems doable. Though you may not be able to intercept the browser produced dialog boxes this way and other dialogs created using Window.alert(). How are you creating the dialogs ?
The tab key is the browser doing the work of changing focus - nothing special needs to be added, you'll find that tab works on any form on the internet (except where explicitly disabled for some reason...).
To move focus with the enter key, you must listen for the onkeydown event (focus change via tab also occurs onkeydown, so selecting this for consistency), check if it was the enter key, and if so, move focus to the next element in the list.
Typical tab focus behavior involves the browser checking the tabIndex of the elements on the page, and finding the next element on the page with a higher tabIndex, or the nearest subsequent sibling/cousin element. I don't have a method to implement this easily, so instead I'm going to focus on just going to the next widget.
GXT 3's FormPanelHelper has some handy methods to look for all Fields - this code could be used as a basis for non-GXT fields as well. Track all FocusEvent and BlurEvent from the fields found in the dialog, and use that to always track the currently focused field. Add a key handler to the dialog itself, to capture all key events, and check if one is the enter key. If so, figure out what the next field is from the currently focused field, and invoke .focus() on it - this will trigger the focus handler described above, so your bookkeeping will be updated correctly.
And as #eliran-m noted, consider leaving the tab key alone - don't get in the way of users navigating the way they are used to. Adding new functionality might be a good thing, but taking away expected behavior probably isn't.
Current solution:
user clicks on label and it is switched with a textarea to allow edit
user can leave edit with tab / enter and textarea is switched back to a label
The problem is the user has to click on the label with a mouse to get into edit mode.
I would like the label to recieve an onFocus event when the user clicks the TAB key and the label is the next widget in line.
Possible soulution (but have not tried yet) to inherit a new widget from the Label widget and implement the TabListener interface.
There is a panel called the focus panel. That panel allows widgets that normally dont receive events like keyboard events (e.g., a label is one) to have events.
checkout the docs here