This is a copy of a feature request I made on GitHub. DSCaskey suggested that I open a discussion here about preferences.
Seamly2D uses dialogs to enter formulas and numbers while drafting a pattern. When I open one of those dialogs, I almost always want to type a new number of formula into the first available text field.
Current behavior : The cursor moves to the OK button. The user has to click to focus the field.
Desired behavior : The cursor automatically moves to the first text field and selects all of the text in the field. For example, in the “Point at Distance and Angle” dialog, it would select all of the text in the Length field automatically.
DSCaskey suggested that I do this with a user preference to not break current users:
Add a group box “Dialogs” to the Graphics->Behavior, with a checkbox:
Set focus to first formula field.
The default behaviour would continue to be that the focus goes to the OK button.
Open questions
Are there other places you would want the focus to go?
Are there tools/dialogs where this behaviour would be helpful?
Are there tools/dialogs where you definitely would not want this behaviour?
I agree that the focus should be on the first available text field when a tool dialog opens, & that having the text of that field selected by default would be good.
The Move tool is the only one which currently has the first text field as the object in focus, though the text is not selected. Furthermore, pressing Enter to OK it still works, though only as long as that field, (or, presumably, the OK button itself,) is in focus.
My preferred behavior would be: Enter/Return always OKs, (barring the few fields off the drafting space where a carriage return is actually relevant,) Esc always Cancels, (this appears to be the case,) Tab always selects the next input, (not object.)
This won’t happen if the focus is initially set to the 1st field. OK is the initial focus as this is the normal default behavior for dialogs. That’s why I suggested to @anteater to make this a user preference option to set the behavior. Also if the text is highlighted, pressing Enter (or any other keyboard event for that matter) will delete the text - unless you put in place an event filter to grab a specific key event, handle it, and not pass the event on. That’s why the app currently places the cursor at the end - unhilighted - so that when you type you’re appending.
That’s also why the default behavior - at least in Windows- is that a double click on a field selects (hightlights) the text. Having a field initially selected is outside the expected norm. With the exception where the text is a placeholder that is expected to be replaced - like asking for a filename.
The esc key gets handled separately… it was one of those Mac issues. The tab will always select the be the object (widget) in the dialog, unless again, an event filter is installed to trap the Tab, and then sone routine is implemented to sort through the list of objects, figuring out what the next “text” field is… which could be anywhere on the dialog, unless the form is (re)sorted so the text fields are is order- assuming top to bottom.
I would say it should be consistent across all the tools where applicable. That: any tool that has any text fields, and an option is set to select 1st field, then the 1st field should gain focus. Picking and choosing different tools to use a different behavior is probably not a good idea.
I was afraid that would be the case. Would it at least be possible for (only) the current object to be clearly highlighted? As it is, OK is highlighted unless Cancel or Apply are the focused object, & nothing else is. Seeing where the focus is would, if not my ideal, be fantastic.
Not sure what you mean? When an dialog object (widget) is the focus it is either highlighted - like buttons, or the cursor is placed in a text box. With a text box double clicking then selects and highlights the text. Having a text box automatically selected and highlighted goes against normal behavior, unless like I stated previously where the text is kust a placeholder that is expected to be replaced. Like in the New pattern dialog, where the default filename is highlighted. If the focus is set to the 1st text field in a dialog, and the text is selected, I can see a lot of users deleting what was there as soon as they type trying to add to the formula. One has to remember, while you might want to overwrite the initial length that the tool visualization created, but you dont want that behavior everytine you edit the tool. You will just have the opposite issue, where you need to remember to click in the blank space to turn off overwrite mode for the text field. It’s why I suggested to @anteater to make any change in behavior an option, with the default pref left the way it currently is.
Also I prefer to leave OK as the initial focus on tool dialogs, as many times for those new tools that pop up the dialog simply needs to be saved - OK’d. If the 1st text box is the focus, now you have to remember to double click OK, or once before hitting enter. Again the default focus of dialogs is generally to do no harm or loose data , thus OK is focused, and you have to make a conscious effort to exit without saving, either by selecting cancel, (Window) close or hitting Esc.
I would also recomend adding a keyboard shortcut to toggle any option to change the focus behavior - which eliminates the need of opening and navigating the prefs dialog to change the setting. This also requires additional code to make the changes take immediate affect, and not having to restart the app, as well as updating the Help → Keyboard Shortcuts dialog.
I mean highlighting the object, not highlighting the text of the field. On my computers, there is a special blue/cyanish border around the OK button unless I tab through the objects to the Cancel or Apply button, in which case they gain the highlighting frame. But there is no indication while tabbing through of which object is in focus, (except the little stick cursor when a text field is in focus,) & the highlight around the OK button is making it look like hitting enter should press the OK button. A bold/colorful outline (highlight) around the object in focus would make the tabbing experience more intuitive.
But as to selecting the text, though that would be my preference, having the cursor active in the first field, like is the case with the Move tool, would also be a sight better than the current state of affairs, & I hope the preference would be between Move style dialog action in all the dialogs and highlighting the text of the first field.
Ok… Since I’m close to getting out of Annie Hell, I was able to take a closer look at the dialog behaviors last night.
Here’s the good news - as I forgot about the formula validation routine - there’s no issue with setting the focus to the 1st text field. Could be a QLineEdit (such as in the Move dialog) or a QPlainText field. For as everytime a formula field gains focus, or the text contents changes, a validation routine is run which if the formula is valid, then the OK button is enabled. In other words, even though another field may be initially set as the focus, the validation routine will still activate the OK and allow one to press Enter to save and exit the dialog.
So @anteater, as per how I described on Github how to set the focus for a given field there should be no issue.
Now we come to the selection / highlighting the text in the text field. Currently the behavior is the place rhe cursor at the end. If we want to have to he option to select the text when focus is gained then heres what I suggest. Modify the CursorToEnd() routine to check a (bool) pref setting whether to select the text or to set the cursor to the end by default. I’d rename the routine to something more descriptive (using lower snake case not upper snake case which should be used for class names). Should be able to use ui->[field name] ->selectAll() to select the text. The highlighting is automatic. This way a user has the choice of cursor at end OR select all text.
In regards to using the Tab in a dialog. This is the behavior in Windows… not sure what it does in Linux or MacOs. When you press Tab, the focus is moved to the next “input” type object / widget. Things like labels and icons are skipped, where text fields, drop downs, spin boxes, tool buttons, etc will gain focus. Also the widget is highlighted… in the case of text boxes line edit or plaintext, the box frame is highlighted (blue). The default behavior is that the text contents is also selected and highlighted. This is the case with lineedits, but do to the CursorToEnd() routine on the plaintextedits, the selection and highting is overridden. Drop downs, spin boxes and tool button will frame either the button or contents with a dashed (black) line… to indicate WHICH object has focus. Tool buttons when highlighted, should execute their action when pressing enter. This is the case with the expansion button, but not the fx button. I don’t know why at this time. The other widgets will execute the OK (as per above with the validation routine) when Enter is pressed - provided text data fields are valid.
Okay. I think I see why I thought it was different now. The place point angle formula button gets focused out of turn, & the expansion buttons don’t highlight when they gain the focus.
Is arranging the tool dialog objects so that they tab in order something that someone with only a little XML experience could do, or is it something best left for when y’all devs have an open slot?
No… they do. It’s a dashed line frame around the button. They do expand upon pressing Enter if you tab to one of them. The Fx buttons on the other hand while they also highlight with the dashed frame, and they exit the dialog if you press enter. They should open the Fx dialog. I’d have to check, but it maybe that the OK CheckState() is being called just like for the text boxes, while the expand buttons are not.
Which BTW, something else I suggested on the Github issue… we should make Shift - Enter open the Fx dialog if the focus is on a formula text box.
The order is set in the ui form… which I believe can be edited in Creator. Which in of itself requires a bit experience using… it’s not very intuitive, so it’s hard to find where / how to add/ edit somethings. Trying to edit the dialog ui file directly is not for the feint of heart. It’s easy to get lost in the multiple nesting levels - especially on the MainWindow form which I’ve had to manually edit multiple times when there are conflicts in a merge commit.
Hey, speaking of which… would you like to see a more "obvious " highlighting on some of the objects? It’s possible I could look at using more of the style sheet options when I get back to updating the dialogs… ahem again.
BTW… in case I’m misreading… is this on just 1 dialog or all of them for you? I know even on the Windows ver it’s hard to see the black dashed frame around small buttons. I know I had to look around to see that indeed some of the bottons where highlighted when I tabbed. It’s also possible that maybe changing the button’s frame properties could help the visiblity?? I’ll try and edit a dialog and see if there is any improvement.
All I have tested since going back to see why we seemed to be having such different experiences. The text boxes get the cursor, but not the bluing of their frame; the expansion buttons don’t get any sort of highlight; most of the objects the grey frame turns a similar saturation of blue; most of the time several objects tab out of order; & the OK button stays highlighted even when it isn’t available for enter, but not in all circumstances.
Right now I have the Arc creation dialog open
OK is blue-framed
Formula button on top is blue-framed, OK is blue-framed
Text on top has cursor, OK is blue-framed
Nothing highlighted, top expansion button has focus
Text in middle has cursor, OK is blue-framed
Nothing highlighted, middle expansion button has focus
Text on bottom has cursor, OK is blue-framed
Nothing highlighted, bottom expansion button has focus
Center point drop-down is blue-framed, OK is blue-framed
Color is blue-framed, OK is blue-framed
Formula button in middle is blue-framed, OK is blue-framed
Formula button on bottom is blue-framed, OK is blue-framed
Linetype is blue-framed, OK is blue-framed
Apply is blue-framed
Cancel is blue-framed
Numbered according to how many times Tab has been pressed. Most of the time that OK is lit, enter works it, but not when a text field is in focus.
And when you are trying to modify the dialogs,
can you try to add the possibility to move the dialog position with the mouse-press-and-move on the title bar?
Or change the standard position to be top left via option?
There’s 2 different types of text boxes… the single line - QLineEdit, and the (formula) multiple line - QPlainTextEdit. There is no change in the line edit behavior. The plain text box overrides the selection / (blue) highlighting with the cursor at the end. That’s why I suggest to make it an option to select the text so as to retain the current behavior.
I don’t have internet at home yet, otherwise I’d post pics… but again the expansion buttons should be getting a grey / black dashed line around the image content… same as the fx buttons - if it varies from dialog to dialog it could be a difference in the form properties.
At any rate, you’re going to love this… I cracked the code so to speak for the focus, tabbing, and styling in dialogs last night. When I update the dialogs I will fix any ordering issues, as well as improving the visibility (and look) of WHICH object has focus. For example here is the Fx button I played with:
When in focus the border would highlight blue. Also you might note the button has rounded corners as well as a gradient fill.
I also know why the Fx button (and possibly others in other dialogs) when in focus exits with Enter… but a bit beyond the scope of this topic.
the expansion buttons don’t get any sort of highlight; 
most of the objects the grey frame turns a similar saturation of blue; most of the time several objects tab out of order; & the OK button stays highlighted even when it isn’t available for enter, but not in all circumstances.
