Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature: move cursor to first text field when opening dialogs #679

Closed
fenichel opened this issue Sep 20, 2022 · 10 comments
Closed

Feature: move cursor to first text field when opening dialogs #679

fenichel opened this issue Sep 20, 2022 · 10 comments
Labels
enhancement UI won't fix

Comments

@fenichel
Copy link

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 does not automatically move to any of the fields. 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.

image

I would like to fix this. Can you point me to the correct area of the code?
@DSCaskey
Copy link
Contributor

DSCaskey commented Sep 20, 2022 via email

@fenichel
Copy link
Author

Thanks for the feedback! I understand that there isn't obviously one right type of behavior, which is why I filed a feature request before diving too far into the code.

The fact you're asking where in the code, this is leads me to believe
you're not familiar enough with the Qt widgets, dialogs, and event
handlers.

That's correct. I normally work in TypeScript and JavaScript--I maintain Blockly as my day job. I'm still learning about the Qt event system and getting used to the debugging setup.

I did dig around a little to see that there's a dialogtool base class for many of the tools that I use in the drafting section of the program. Is that the correct base class to look at?

Since you're proposing changing the default behavior existing dialogs -
which places the focus on the OK button - the proper thing to do is add
this as a user option.

Makes sense. Is #603 a good example for how to add a user option?

Not all users may want the 1st field selected.

I think it makes sense for the user option to be one of

  • Focus OK button
  • Focus first text field
  • Focus first selectable thing in the widget (formula icon in the image above)

@DSCaskey
Copy link
Contributor

which is why I filed a feature request before diving too far into the code.

Appreciated. That being said, you might consider joining the Seamly forums, where you could get even more feedback than just my opinion. The forums has many users that are familiar with the apps that may suggest ideas to improve a feature idea - even before creating an issue. Even though I have tons of ideas and know the code better than most, I like to run ideas by the longtime users. More often than not, many features I add come with a pref option so as to not change a behavior current users are used to.

DialogTool

Yes and No. That base class handles stuff common to all the tool dialogs... including an event filter that determines the behavior of the qplaintextedit widgets, but it does not know the ui name of each qplaintextedit widgets in each dialog (which BTW are also widgets... everything in the ui is widget... that's why every widget except mainwindow has a parent widget. QWidget is a base class which provides all the widget methods as well as the base class QObject that provides the signal & slot functionality).

More to your original question... to change the focus of a dialog you need to set the focus to another ui object in each dialog's constructor... therefore given 50+ tools, 50+ places to change the focus.

First you need to know the ui name of the object you wish to set the focus to - again OK button generally being the default for dialogs - and then simply for ex:

ui->plainTextEditFormula->setFocus(Qt::OtherFocusReason);

To set the focus to THAT field.

To change what happens when that text field gains focus requires changing the behavior of a QPlainTextEdit... currently the cursor is set to the end of the text as per the event filter in DialogTool. As an aside another option would be to subclass QPlainTextItem, and use that class in the dialog forms instead of QPlainTextEdit. That way you can choose which dialogs and / or have a different text edit behavior. Again, unless it's like a field asking for a new pattern name, it's not a good idea to select (and highlite) the text, for as soon as you hit any key the text is deleted. A subclassed text widget would limit this to only those fields you choose, and not EVERY QPlainTextedit if you chose a select all behavior.

Makes sense. Is #603 a good example for how to add a user option?

That setting also incorporates defining which file format to save as... you only need a bool checkbox setting. The recent Issue 644 includes an option which behavior the pan spacebar shortcut uses. A few notes on using the settings... each setting needs a getter and setter - they could be considered read / write, but settings are put in a queue, and only written when the system has time. Also, you need to know how to edit ui forms in Creator properly to edit the (prefs) dialogs, or it's real easy to muck up the nested QLayouts that allow for the dynamic sizing of the (dialog) forms. It took me quite awhile to grasp this concept. Creator is not the most intuitive application. Also in the getter you definitely need to provide a default setting so that when a user updates to a new ver of the app with a settings addition, and reads the (new) settings for the first time - which are empty - they're not confronted with some new behavior they're not used to. In other words, a default should be the old behavior.

As far as the prefs go... I'd add a group box "Dialogs" to the Graphics->Behavior, with a checkbox:

[ ] Set focus to first formula field.

An OK Button item is probably not necessary, as that's an understood default. Unless there are other options, then a radio button to select which one would the way to go. I get where you're going with the fx icon... I think a better option may be to change the event filter to open the Formula dialog with Shift - Enter on a plain text field... you have to click the fx button or hit enter anyhow. This way the same behavior happens with any formula field. And you definitely don't want to have the fx dialog open up automatically on opening a tool dialog.

I guess that's enough for you to chew on.
Cheers

@DSCaskey
Copy link
Contributor

Just playin around a bit...

In the tool dialogs will call DialogTool::MoveCursorToEnd

For ex in the dialogendline.cpp: MoveCursorToEnd(ui->plainTextEditFormula);

You can replace that with:
ui->plainTextEditFormula->selectAll();

That will highlight just the "length" formula.

Only downside to that maybe is, if you use the fx dialog to change the length formula, the length field will be highlighted again.

:)

@fenichel
Copy link
Author

I created a topic in the forum to ask for feedback. I like the suggestion that shift - enter on a plain text field should open the associated fx dialog, regardless of the first-focus behaviour. Should I create a separate issue if I want to work on that?

@DSCaskey
Copy link
Contributor

DSCaskey commented Sep 29, 2022 via email

@fenichel
Copy link
Author

Well, work caught up with me pretty badly. I am not working on this in the foreseeable future :/

@slspencer slspencer added the UI label Jan 6, 2023
@slspencer
Copy link
Collaborator

@DSCaskey - Is this a "won'tfix"

@DSCaskey
Copy link
Contributor

DSCaskey commented Jan 7, 2023 via email

@slspencer
Copy link
Collaborator

Closed. Won't fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement UI won't fix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@slspencer @fenichel @DSCaskey