1. The window title "**Question**" is not really that appropriate, and confuses more than explains. Better would be for example "**Wrap search?**" 2. The line "**'String' was not found.**" is actually wrong. When the string was not found, the search field gets red and in the status bar it says exactly "'String' was not found." But whenever this "Question" window is shown, it always means that the **search has reached the end of the file**, and it would like to start from the beginning (not necessarily "again" - see point 3.) in order to confirm that the string was really not found. 3. "**Wrap search and find again?**" I think " and find again" here is unnecessary. Just "**Wrap search?**" would suffice. 4. The "**Find**" button perhaps should better be "**Wrap**". 5. #1192 The default button should indeed be **Yes/OK/Wrap/Find** (not Cancel). 6. #2159 When the wrap is done, perhaps it should also **say that in the status bar** (or it should be muted if the feature "Show message in the status bar when the search is wrapped" will be implemented and "Always wrap search" option is disabled)
The window title "Question" is not really that appropriate, and confuses more than explains. Better would be for example "Wrap search?"
Dialogs are categorised into errors, warnings and questions, its telling you its not an error or warning, ie nothing is wrong, it just wants to know what to do next. Thats a question.
The string _was_ not found in the part of the document searched so far, maybe it could be `"string" was not found between the start of the search and the end of document`, but then the dialog is getting big and wordy. The find is indeed run "again" from the start of the document.
A standard dialog is used for these questions and "Find" is a stock button. I doubt "wrap" is. If "wrap" is one then its probably fine to change, pull requests are welcome.
"Cancel" is the standard GTK GUI button in accordance with the human interface guidelines for "Cancel the operation and close the dialog". It should not be changed.
If my suggestion in #1192 was taken:
Alternatively it might be easier to just create an ad hoc dialog normally at the call site and set it up as needed, to avoid affecting all the callers of dialogs_show_question_full() and friends.
Then the first and fourth items would be trivial to solve compared with trying to adapt the general purpose helper dialog function which is currently in use.
Personally I think it'd be nice to get rid of this modal dialog and find another way to let the user know the search wrapped back to the start. One rather nice example is QtCreator which flashes/fades in/out a "referesh" type of icon, overlaid on the middle of the editor like this:
Replacing general purpose dialogs is just a MMOP, pull requests are welcome.
Personally I think it'd be nice to get rid of this modal dialog and find another way to let the user know the search wrapped back to the start.
Agree if automatic wrapping is selected on, but then the dialog doesn't appear anyway. Making a wrap message in the status bar is in #2159.
But if automatic wrapping is off the dialog is asking "do you want to?" so its got to be a user interaction.
Personally I would be happy to remove the option and have searches always wrap, then we needs no dialogs, but I understand that others may see it differently.
Personally I would be happy to remove the option and have searches always wrap, then we needs no dialogs
:+1:
but I understand that others may see it differently.
As is often the case (didn't check here), stuff like this is just the way it is because that's how the person who wrote the code initially did it, and nobody bothered to improve it yet.
but then the dialog is getting big and wordy
I think `"string" was not found from cursor` is more accurate, and that wording also works for *Find Previous*.
The default button should indeed be [Find] (not Cancel).
I agree here, if the user wants to cancel the dialog they can press escape.
github-comments@lists.geany.org