-
Notifications
You must be signed in to change notification settings - Fork 41
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.
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
IP Address input value control - move validation and persistence out from onTextChanged into onEditingFinished but needs UI change (maybe adding a new "done" button) #438
Comments
Here is a reference for this pattern, from editing your name in iOS account settings. There are probs some details we should define, like:
Just some thoughts. What are yours? |
I agree, makes sense, that could work.
I was thinking on that yesterday night and I was going to create a separate issue today, because other settings could need this feature as well. (edit: #419)
I need to check, perhaps we could ask the user if he want to restart and do it for him. At the moment in Qt requires manual restart from the user.
Yes, losing focus makes sense to validate but to persist the value only with "Done". Also in the proxy settings we have the default proxy and the tor one, this "Done" is for both? Or independent: the user needs to finish with "done" the default before modifying the tor? And then as soon the default's "done" disappears another would come back if the user starts editing the tor input? |
Brings the mock-ups in line with the recent work in issues and PRs. For max upload limits: #8 For the proxy screen: #43 bitcoin-core/gui-qml#438
Brings the mock-ups in line with the recent work in issues and PRs. For max upload limits: #8 For the proxy screen: #43 bitcoin-core/gui-qml#438
…om the UI into the model/ interface 4dea7c9 qml, proxy: Allow IPv6 and move out UI validation (pablomartin4btc) Pull request description: The main purposes of this PR are: - Allow configure proxy server with IPv6 (after testing exhaustively in current `bitcoin-qt` [repo](https://github.com/bitcoin-core/gui/) and `bitcoind` - e.g. [IPv6 on Qt](bitcoin-core/gui#836 (comment)); [IP validation in Qt](bitcoin-core/gui#813)) - More importantly: moving the validation logic out from the UI (component/ control/ widget) into the back-end (model/ interfaces). It seemed currently in [Qt](https://github.com/bitcoin-core/gui/) all this logic (validation, network classes) was coupled to the UI since the beginning (more than [12y ago](https://github.com/bitcoin-core/gui/blame/c4443c2be141e5f45bb10376056f3083e97cde50/src/qt/optionsmodel.cpp)) instead of using interfaces (introduced much later) that would be the correct thing to do. Feedback and suggestions are very welcome and will help establish a foundation for leaving business logic out of the UI going forward. --- <details> <summary>In order to test it, if it's the first time you run <code>./src/qt/bitcoin-qt</code> you need to go thru the on-boarding flow (<i>start->next->next->next->next->connection settings->Proxy settings</i>) otherwise you need to go to the settings (top right gear icon) then <i>Connection->Proxy settings</i>.</summary> ![image](https://github.com/user-attachments/assets/9f10c4b7-b7e4-4807-b895-1c03d9c00037) </details> Before this change, only IPv4 address were allow in the value input, now also IPv6 can be entered. --- There are some [look and feel kind of issues](#430 (comment)) that will be handled on follow-ups (issues: #437 and #438). ACKs for top commit: D33r-Gee: tACK [4dea7c9](4dea7c9) on Ubuntu 20.04 works as expected. vasild: ACK 4dea7c9 johnny9: ACK 4dea7c9 Tree-SHA512: f633f5729f4ca2a8433560b15722bccd5938bfa55643cd3d925b75ed01006dbc7a56fe3a20766a6bb9e2bb601c8a3828c177de3cccc7728959eb48987838e90c
Now, every time a user types into the ip address input value, the value is validated and persisted (if #433 gets merged), this is because of the nature of the app design, there's no where to "accept" the changes or land after editing a value. Originally the validation was triggered in the editing finished but it seemed more correct to move it into the text change due to the above reason. But when we added the persistence logic (#433), didn't feel right anymore, so @GBKS suggested to add a "done" button when we revert back to the correct event again:
The text was updated successfully, but these errors were encountered: