String picker search field #701

New Issue

2025-03-20T00:43:30Z

NQNStudios commented

2025-03-20 00:43:30 +00:00

(Migrated from github.com)

It will fit at the top of the dialog, there's some blank space by the dialog picture. You'll type into it and click a Search button. It'll do a case-insensitive search of the strings starting from the current page. It'll set a highlight color on matching strings. If there are none on the current page or you hit the button twice, it'll proceed to the next page with a match. It can have a little label that might tell you 'No matches' or 'Reached end, looping'

NQNStudios commented

2025-03-20 21:35:50 +00:00

(Migrated from github.com)

@CelticMinstrel Here's how it looks:

One thing that's troublesome is you expect 'Enter' to run the search you've typed in, but it clicks OK instead. But I'm not so sure making the search button the default would be good to do in every string picker. And whether it (the search feature) should be made optional per dialog type. Maybe it could automatically appear for multipage pickers?

For the 'give item' debug action picker shown here what I'd like is for the search to be Enter and the "OK" button to say "Give", with g as its key.

@CelticMinstrel Here's how it looks: <img width="606" alt="Image" src="https://github.com/user-attachments/assets/67c08782-ad12-4dba-9fbb-d9cb244777df" /> One thing that's troublesome is you expect 'Enter' to run the search you've typed in, but it clicks OK instead. But I'm not so sure making the search button the default would be good to do in every string picker. And whether it (the search feature) should be made optional per dialog type. Maybe it could automatically appear for multipage pickers? For the 'give item' debug action picker shown here what I'd like is for the search to be Enter and the "OK" button to say "Give", with g as its key.

CelticMinstrel commented

2025-03-21 00:06:08 +00:00

(Migrated from github.com)

One thing that's troublesome is you expect 'Enter' to run the search you've typed in, but it clicks OK instead. But I'm not so sure making the search button the default would be good to do in every string picker.

Hmm, yeah, this design is a bit troublesome. From what I recall, the notion of "focus" in dialogxml is very basic, and there is no concept of having no field focused. If that concept existed, my expectation would be to hit search if the field has focus and hit OK if it does not.

But, there are other options that come to mind.

Remove the text field and "reverse" toggle - just have a search button. That brings up a separate search dialog where you enter in your query, possibly select reverse, and click OK. The query could still be shown as static text in the dialog. There are still a few issues, but that's similar to how RPGMaker handles search.
The input field is invisible until you press Search. Once it's visible, enter hits Search instead of OK. Perhaps Ctrl+Enter hits OK.

Also, the button should have a keyboard shortcut of Ctrl+F. I also think the status text just below the field should be in a slightly smaller font size.

And whether it (the search feature) should be made optional per dialog type. Maybe it could automatically appear for multipage pickers?

It seems like it would be really hard to generalize it down to something that can be used in any dialog. The specific logic of the search in particular depends on the dialog.

For the 'give item' debug action picker shown here what I'd like is for the search to be Enter and the "OK" button to say "Give", with g as its key.

Changing the label on the button is as easy as choiceDlog->getControl("done").setText("whatever"). Not sure if changing the key is equally easy.

> One thing that's troublesome is you expect 'Enter' to run the search you've typed in, but it clicks OK instead. But I'm not so sure making the search button the default would be good to do in every string picker. Hmm, yeah, this design _is_ a bit troublesome. From what I recall, the notion of "focus" in dialogxml is very basic, and there is no concept of having _no_ field focused. If that concept existed, my expectation would be to hit search if the field has focus and hit OK if it does not. But, there are other options that come to mind. 1. Remove the text field and "reverse" toggle - just have a search button. That brings up a separate search dialog where you enter in your query, possibly select reverse, and click OK. The query could still be shown as static text in the dialog. There are still a few issues, but that's similar to how RPGMaker handles search. 2. The input field is invisible until you press Search. Once it's visible, enter hits Search instead of OK. Perhaps Ctrl+Enter hits OK. Also, the button should have a keyboard shortcut of Ctrl+F. I also think the status text just below the field should be in a slightly smaller font size. > And whether it (the search feature) should be made optional per dialog type. Maybe it could automatically appear for multipage pickers? It seems like it would be really hard to generalize it down to something that can be used in any dialog. The specific logic of the search in particular depends on the dialog. >For the 'give item' debug action picker shown here what I'd like is for the search to be Enter and the "OK" button to say "Give", with g as its key. Changing the label on the button is as easy as `choiceDlog->getControl("done").setText("whatever")`. Not sure if changing the key is equally easy.

NQNStudios commented

2025-03-21 00:21:44 +00:00

(Migrated from github.com)

Hmm, yeah, this design is a bit troublesome. From what I recall, the notion of "focus" in dialogxml is very basic, and there is no concept of having no field focused. If that concept existed, my expectation would be to hit search if the field has focus and hit OK if it does not.

I was thinking that a kludgy concept of 'focus' could be added to this specific dialog, by manually toggling the dialog's default button in response to:

Selecting an LED -> make the OK button default
Typing in the search field -> search button becomes default
clicking on the search field -> search button
clicking the search button -> search button
toggling the reverse led -> search button

> Hmm, yeah, this design is a bit troublesome. From what I recall, the notion of "focus" in dialogxml is very basic, and there is no concept of having no field focused. If that concept existed, my expectation would be to hit search if the field has focus and hit OK if it does not. I was thinking that a kludgy concept of 'focus' could be added to this specific dialog, by manually toggling the dialog's default button in response to: * Selecting an LED -> make the OK button default * Typing in the search field -> search button becomes default * clicking on the search field -> search button * clicking the search button -> search button * toggling the reverse led -> search button

NQNStudios commented

2025-03-21 00:23:15 +00:00

(Migrated from github.com)

It seems like it would be really hard to generalize it down to something that can be used in any dialog. The specific logic of the search in particular depends on the dialog.

I meant multipage string pickers.

> It seems like it would be really hard to generalize it down to something that can be used in any dialog. The specific logic of the search in particular depends on the dialog. I meant multipage string pickers.

NQNStudios commented

2025-03-21 01:42:58 +00:00

(Migrated from github.com)

The input field is invisible until you press Search. Once it's visible, enter hits Search instead of OK. Perhaps Ctrl+Enter hits OK.

I went with this solution.

> The input field is invisible until you press Search. Once it's visible, enter hits Search instead of OK. Perhaps Ctrl+Enter hits OK. I went with this solution.

CelticMinstrel commented

2025-05-22 18:02:10 +00:00

(Migrated from github.com)

By the way, does this work in the editable string picker too?

NQNStudios commented

2025-05-22 18:08:42 +00:00

(Migrated from github.com)

No.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: openboe/oboe#701