Maintain InputText selection state/active widget after menu usage #622

New issue

Open

opened 2016-04-29 16:49:36 +00:00 by pdoane · 2 comments

pdoane commented

2016-04-29 16:49:36 +00:00

(Migrated from github.com)

I would expect that interacting with either the window's menu bar or the global menu bar to not modify the active widget or its state.

If I click on a menu bar while a text input widget is active with a selection, that selection is lost after interaction with the menu bar is complete. It also looks like the text input widget is no longer active. I would expect that interacting with either the window's menu bar or the global menu bar to not modify the active widget or its state.

ocornut commented

2016-04-29 17:04:38 +00:00

(Migrated from github.com)

That's correct. That sort of focusing behavior isn't supported at all yet. It would be a rather non-trivial feature to extend ImGui toward that - compared to IHMO the benefits. But doable. I am adding a note to myself that the enhancement is desirable but it would be rather low in the priority list at the moment.

ocornut commented

2016-05-03 07:55:35 +00:00

(Migrated from github.com)

Quick ideas and thinking aloud.

At the time of stealing focus from a window we could store e.g. a LastActiveId within ImGuiWindow, which could then be restored upon restoring focus when popping from OpenPopupStack. Pretty much that (plus/minus dozen of edge cases).

The problem is that we only store 1 instance of state for InputText(), so restoring focus on a text input after another has been used would lose cursor position, undo stack, etc. It may or not be a problem for you.

The majority of that stored space are the undo buffers (currently hardcoded to be ~3K). We could probably devise a general scheme for storing cursor/selection for all visible InputText(), not as much a problem of storage space there but design (when to store/restore).

Undo buffer is a little more tricky. Keeping undo data when the InputText() isn't active (when it "owns" the text) opens issues and may not play well with end-user code who may have larger-scale undo in place. (It is currently already a problem if you use text input, un-select, mess up with data outside of imgui, select text input again and use redo/undo. I could compare hash of text between last unselect and current time see if undo-buffers are still valid).

We could add options to InputText() to e.g. disable undo-buffer; request persistent undo-buffer for this instance; request semi-persistent undo-buffer for this instance, ditched when id disappear, etc.

So at the end of the day most of the work for this feature wouldn't be maintenance of ActiveId state but rather work on InputText() - unless you don't care about the text selection.

May work on #323 at some point and this would probably requires maintain a stack of focused/selected items when popups are used.

Quick ideas and thinking aloud. At the time of stealing focus from a window we could store e.g. a LastActiveId within ImGuiWindow, which could then be restored upon restoring focus when popping from OpenPopupStack. Pretty much that (plus/minus dozen of edge cases). The problem is that we only store 1 instance of state for InputText(), so restoring focus on a text input after another has been used would lose cursor position, undo stack, etc. It may or not be a problem for you. The majority of that stored space are the undo buffers (currently hardcoded to be ~3K). We could probably devise a general scheme for storing cursor/selection for all visible InputText(), not as much a problem of storage space there but design (when to store/restore). Undo buffer is a little more tricky. Keeping undo data when the InputText() isn't active (when it "owns" the text) opens issues and may not play well with end-user code who may have larger-scale undo in place. (It is currently already a problem if you use text input, un-select, mess up with data outside of imgui, select text input again and use redo/undo. I could compare hash of text between last unselect and current time see if undo-buffers are still valid). We could add options to InputText() to e.g. disable undo-buffer; request persistent undo-buffer for this instance; request semi-persistent undo-buffer for this instance, ditched when id disappear, etc. So at the end of the day most of the work for this feature wouldn't be maintenance of ActiveId state but rather work on InputText() - unless you don't care about the text selection. May work on #323 at some point and this would probably requires maintain a stack of focused/selected items when popups are used.