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.

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

Give primary action items more visual weight #24

Closed
statusquont opened this issue Jul 2, 2020 · 14 comments · Fixed by #39
Closed

Give primary action items more visual weight #24

statusquont opened this issue Jul 2, 2020 · 14 comments · Fixed by #39

Comments

@statusquont
Copy link

The Receive panel indicates that "all fields are optional" and if that is indeed the case, there is no clear visual cues what the correct action is -- it's to click the 'Create New Receiving Address' button.

Suggestion: give primary action buttons an orange background.

image

Here's an example from GitHub settings where a UI has multiple actions, but they visually guide the user to the action they should be taking with a colored button.

image

@Sjors
Copy link
Member

Sjors commented Jul 2, 2020

More emphasis on the primary action makes sense. I think there's a QT standard way of marking buttons as such:
Schermafbeelding 2020-07-02 om 20 44 50

Schermafbeelding 2020-07-02 om 20 45 52

@hebasto
Copy link
Member

hebasto commented Jul 11, 2020

@Sjors
Unfortunately, on Linux it looks not such emphasized:

Screenshot from 2020-07-11 11-22-27

@Sjors
Copy link
Member

Sjors commented Jul 17, 2020

I see a subtle blue line around Hide. Can you show a screen with more than 1 button? Doing non-native styling can get real ugly real fast in my experience.

@hebasto
Copy link
Member

hebasto commented Jul 17, 2020

@Sjors

I see a subtle blue line around Hide. Can you show a screen with more than 1 button?

Qt 5.9.8 (static):
Screenshot from 2020-07-17 12-50-30

Qt 5.12.8 (dynamic):
Screenshot from 2020-07-17 12-35-52

Doing non-native styling can get real ugly real fast in my experience.

Agree.

@Sjors
Copy link
Member

Sjors commented Jul 17, 2020

I think these are both clear enough, the static build (which we ship) is the most clear.

So in the original example, maybe we just need to mark the Receive button as primary?

@hebasto
Copy link
Member

hebasto commented Jul 17, 2020

I think these are both clear enough, the static build (which we ship) is the most clear.

So in the original example, maybe we just need to mark the Receive button as primary?

Actually, in a such way not the "primary action" button highlighted rather the focused one.

@hebasto
Copy link
Member

hebasto commented Jul 19, 2020

@statusquont
Mind providing an example among desktop widget-based applications to find the solution without non-native styling?

@statusquont
Copy link
Author

I'm not sure if I understand what you're asking for, but hopefully this helps, from the GitHub Desktop application (Windows).

image

If I misunderstood the question please advise.

@hebasto
Copy link
Member

hebasto commented Jul 21, 2020

Concept ACK.

To implement this feature into the code (say, "primary push button") some design decisions are required to make it harmonized with the used styles on all supported platforms.

It could be made as artworks, e.g., https://doc.qt.io/qt-5/gallery.html

Doing non-native styling can get real ugly real fast in my experience.

That is it what we should avoid for sure.

@statusquont
Copy link
Author

Yeah, that makes a lot of sense. IMO a good design should be there to help a user make decisions, but other than that, get out of the way and don't cause distraction.

I'm not too familiar with QT, but I would presume (and hope) that efforts have been made in that project to consider usability for all types of users (including vision impaired for example) and design the UI accordingly. So leaning on QT's prior work makes a lot of sense. In that regard, I'll retract my previous suggestion of "give primary action buttons an orange background" since that seems to be outside of the scope at this time. Perhaps it can be revisited at a later time as the Bitcoin Design working group make further progress to establish a set of visual standards.

To wrap this issue up, I'd just ask whether or not the 'Create New Receiving Address' button is inheriting the default button push properties from QT in order to help the user make a decision?
https://doc.qt.io/qt-5/qpushbutton.html#default-prop

I'm not sure where/how to check the code to answer this question myself.

@hebasto
Copy link
Member

hebasto commented Jul 21, 2020

@statusquont

To wrap this issue up, I'd just ask whether or not the 'Create New Receiving Address' button is inheriting the default button push properties from QT in order to help the user make a decision?
https://doc.qt.io/qt-5/qpushbutton.html#default-prop

I'm not sure where/how to check the code to answer this question myself.

Mind testing #39 ?

@statusquont
Copy link
Author

Looks improved, slightly, but still an improvement nonetheless! 👍

@statusquont
Copy link
Author

Not sure of proper protocol here. Do I close this issue? Or does it auto-close once #39 gets closed?

@hebasto
Copy link
Member

hebasto commented Jul 21, 2020

Not sure of proper protocol here. Do I close this issue? Or does it auto-close once #39 gets closed?

The latter one :)

fanquake pushed a commit that referenced this issue Nov 20, 2020
98fadc0909 Merge #24: Push bool into array correctly
5f03f1f39a Push bool into array correctly

git-subtree-dir: src/univalue
git-subtree-split: 98fadc090984fa7e070b6c41ccb514f69a371c85
jonasschnelli added a commit that referenced this issue Dec 2, 2020
8963b2c qt: Improve comments in WalletController::getOrCreateWallet() (Hennadii Stepanov)
5fcfee6 qt: Call setParent() in the parent's context (Hennadii Stepanov)
5659e73 qt: Add ObjectInvoke template function (Hennadii Stepanov)

Pull request description:

  The `setParent(parent)` internally calls `QCoreApplication::sendEvent(parent, QChildEvent)` that implies running in the thread which created the parent object. That is not the case always, and an internal assertion fails in the debug mode.

  Steps to reproduce this issue on master (007e15d) on Linux Mint 20 (x86_64):

  ```
  $ make -C depends DEBUG=1
  $ CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure
  $ make
  $ QT_FATAL_WARNINGS=1 lldb src/qt/bitcoin-qt -- --regtest -debug=qt
  (lldb) target create "src/qt/bitcoin-qt"
  Current executable set to '/home/hebasto/GitHub/bitcoin/src/qt/bitcoin-qt' (x86_64).
  (lldb) settings set -- target.run-args  "--regtest" "-debug=qt"
  (lldb) run
  Process 431562 launched: '/home/hebasto/GitHub/bitcoin/src/qt/bitcoin-qt' (x86_64)
  # load wallet via GUI
  Process 431562 stopped
  * thread #24, name = 'QThread', stop reason = signal SIGABRT
      frame #0: 0x00007ffff794518b libc.so.6`__GI_raise(sig=2) at raise.c:51:1
  (lldb) bt
  * thread #24, name = 'QThread', stop reason = signal SIGABRT
    * frame #0: 0x00007ffff794518b libc.so.6`__GI_raise(sig=2) at raise.c:51:1
      frame #1: 0x00007ffff7924859 libc.so.6`__GI_abort at abort.c:79:7
      frame #2: 0x0000555556508ec4 bitcoin-qt`::qt_message_fatal((null)=<unavailable>, context=<unavailable>, message=<unavailable>) at qlogging.cpp:1690:15
      frame #3: 0x00005555565099cf bitcoin-qt`QMessageLogger::fatal(this=<unavailable>, msg=<unavailable>) const at qlogging.cpp:796:21
      frame #4: 0x000055555650479d bitcoin-qt`qt_assert_x(where=<unavailable>, what=<unavailable>, file=<unavailable>, line=<unavailable>) at qglobal.cpp:3088:46
      frame #5: 0x0000555556685733 bitcoin-qt`QCoreApplicationPrivate::checkReceiverThread(receiver=0x0000555557b27510) at qcoreapplication.cpp:557:5
      frame #6: 0x00005555567ced86 bitcoin-qt`QApplication::notify(this=0x00007fffffffd4a0, receiver=0x0000555557b27510, e=0x00007fff9a7f8ce0) at qapplication.cpp:2956:27
      frame #7: 0x0000555556685d31 bitcoin-qt`QCoreApplication::notifyInternal2(receiver=0x0000555557b27510, event=0x00007fff9a7f8ce0) at qcoreapplication.cpp:1024:24
      frame #8: 0x00005555566c9224 bitcoin-qt`QObjectPrivate::setParent_helper(QObject*) [inlined] QCoreApplication::sendEvent(event=<unavailable>, receiver=<unavailable>) at qcoreapplication.h:233:59
      frame #9: 0x00005555566c9210 bitcoin-qt`QObjectPrivate::setParent_helper(this=0x00007fff85855260, o=0x0000555557b27510) at qobject.cpp:2036
      frame #10: 0x00005555566c9b41 bitcoin-qt`QObject::setParent(this=<unavailable>, parent=<unavailable>) at qobject.cpp:1980:24
      frame #11: 0x0000555555710be8 bitcoin-qt`WalletController::getOrCreateWallet(std::unique_ptr<interfaces::Wallet, std::default_delete<interfaces::Wallet> >) + 2534

  ...
  ```

  Fixes #18835.

ACKs for top commit:
  ryanofsky:
    Code review ACK 8963b2c. No changes since last review, just rebase because of conflict on some adjacent lines
  jonasschnelli:
    utACK 8963b2c

Tree-SHA512: fef615904168717df3d8a0bd85eccc3eef990cc3e66c9fa280c8ef08ea009a7cb5a2a4f868ed0be3c0fe5bf683e8465850b5958deb896fdadd22d296186c9586
maflcko pushed a commit that referenced this issue Apr 28, 2021
fa1fdeb fuzz: Ensure prevout is consensus-valid (MarcoFalke)

Pull request description:

  It shouldn't be possible to create consensus-invalid prevouts, so there is no need to fuzz them.

  To reproduce:

  ```
  $ echo 'AAAAAAEAAAAAAQF0Rw0SGsrit4+YZSEfpcQT/o+bJbjgVjATUHqrCfRE+QsBAAAXFgAUlsvXHgGV
  ZxF3QXxitwe1tIOYdLj2NePHATl9CgAAAAAAGXapFOFHg1yqRFl7soeowwpIEOoe9G1NiKwCRzBE
  AiAx6F2Q008gvJnok6JiyOn7lPqCJJmDiI2omRNXT1Q7XAIgCQP6WJizAqhnvImpQqYMJkqePGvx
  Jy/pGRMy1iNL0ecDIQJr4tWomVTBfjpyMFMOD9aDAR5gkByOIYiaQOv8P/sRztP3pS8RDAAAEUUE
  NQBwYAAAAAC5F6kUTLIzj/lKP2Hmpwyzukns2eweRkOH' | base64 --decode  > /tmp/a

  $ FUZZ=script_flags ./src/test/fuzz/fuzz /tmp/a
  INFO: Running with entropic power schedule (0xFF, 100).
  INFO: Seed: 59714236
  INFO: Loaded 1 modules   (212532 inline 8-bit counters): 212532 [0x55987fb3f668, 0x55987fb7349c),
  INFO: Loaded 1 PC tables (212532 PCs): 212532 [0x55987fb734a0,0x55987feb17e0),
  ./src/test/fuzz/fuzz: Running 1 inputs 1 time(s) each.
  Running: /tmp/a
  fuzz: script/interpreter.cpp:1495: bool HandleMissingData(MissingDataBehavior): Assertion `!"Missing data"' failed.
  ==520092== ERROR: libFuzzer: deadly signal
      #0 0x55987f111180 in __sanitizer_print_stack_trace (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x5ea180)
      #1 0x55987f0ba828 in fuzzer::PrintStackTrace() fuzzer.o
      #2 0x55987f09de43 in fuzzer::Fuzzer::CrashCallback() fuzzer.o
      #3 0x7fd003d563bf  (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf)
      #4 0x7fd00399a18a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a)
      #5 0x7fd003979858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858)
      #6 0x7fd003979728  (/lib/x86_64-linux-gnu/libc.so.6+0x25728)
      #7 0x7fd00398af35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35)
      #8 0x55987f8ce194 in HandleMissingData(MissingDataBehavior) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1495:9
      #9 0x55987f8ce194 in GenericTransactionSignatureChecker<CTransaction>::CheckECDSASignature(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, CScript const&, SigVersion) const /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1685:68
      #10 0x55987f8cbbc8 in EvalChecksigPreTapscript(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, prevector<28u, unsigned char, unsigned int, int>::const_iterator, prevector<28u, unsigned char, unsigned int, int>::const_iterator, unsigned int, BaseSignatureChecker const&, SigVersion, ScriptError_t*, bool&) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:363:24
      #11 0x55987f8cbbc8 in EvalChecksig(std::vector<unsigned char, std::allocator<unsigned char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, prevector<28u, unsigned char, unsigned int, int>::const_iterator, prevector<28u, unsigned char, unsigned int, int>::const_iterator, ScriptExecutionData&, unsigned int, BaseSignatureChecker const&, SigVersion, ScriptError_t*, bool&) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:421:16
      #12 0x55987f8c5a01 in EvalScript(std::vector<std::vector<unsigned char, std::allocator<unsigned char> >, std::allocator<std::vector<unsigned char, std::allocator<unsigned char> > > >&, CScript const&, unsigned int, BaseSignatureChecker const&, SigVersion, ScriptExecutionData&, ScriptError_t*) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1094:26
      #13 0x55987f8d6d6e in ExecuteWitnessScript(Span<std::vector<unsigned char, std::allocator<unsigned char> > const> const&, CScript const&, unsigned int, SigVersion, BaseSignatureChecker const&, ScriptExecutionData&, ScriptError_t*) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1843:10
      #14 0x55987f8d48fc in VerifyWitnessProgram(CScriptWitness const&, int, std::vector<unsigned char, std::allocator<unsigned char> > const&, unsigned int, BaseSignatureChecker const&, ScriptError_t*, bool) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:1904:20
      #15 0x55987f8d3d8b in VerifyScript(CScript const&, CScript const&, CScriptWitness const*, unsigned int, BaseSignatureChecker const&, ScriptError_t*) /root/fuzz_dir/scratch/fuzz_gen/code/src/script/interpreter.cpp:2045:22
      #16 0x55987f201d47 in script_flags_fuzz_target(Span<unsigned char const>) /root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/script_flags.cpp:54:30
      #17 0x55987f11447f in std::_Function_handler<void (Span<unsigned char const>), void (*)(Span<unsigned char const>)>::_M_invoke(std::_Any_data const&, Span<unsigned char const>&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300:2
      #18 0x55987f8aed17 in std::function<void (Span<unsigned char const>)>::operator()(Span<unsigned char const>) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14
      #19 0x55987f8aed17 in LLVMFuzzerTestOneInput /root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz.cpp:63:5
      #20 0x55987f09f5e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o
      #21 0x55987f0894e2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o
      #22 0x55987f08f2da in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o
      #23 0x55987f0bb002 in main (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x594002)
      #24 0x7fd00397b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
      #25 0x55987f06420d in _start (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x53d20d)

  NOTE: libFuzzer has rudimentary signal handlers.
        Combine libFuzzer with AddressSanitizer or similar for better crash reports.
  SUMMARY: libFuzzer: deadly signal

ACKs for top commit:
  practicalswift:
    Tested ACK fa1fdeb

Tree-SHA512: 6130ed9ab6d8eeab901f64a1c069300e67d0b6009c42763262fe6edeab8192e088c1a3c1f61aee900b9ebbc48fbf6e837b41704bad592ec526398355766e208a
maflcko pushed a commit that referenced this issue May 15, 2021
…st RPC

fa2e614 test: Fix off-by-one in mockscheduler test RPC (MarcoFalke)

Pull request description:

  Fixes:

  ```
  fuzz: scheduler.cpp:83: void CScheduler::MockForward(std::chrono::seconds): Assertion `delta_seconds.count() > 0 && delta_seconds < std::chrono::hours{1}' failed.
  ==1059066== ERROR: libFuzzer: deadly signal
      #0 0x558f75449c10 in __sanitizer_print_stack_trace (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x5fec10)
      #1 0x558f753f32b8 in fuzzer::PrintStackTrace() fuzzer.o
      #2 0x558f753d68d3 in fuzzer::Fuzzer::CrashCallback() fuzzer.o
      #3 0x7f4a3cbbb3bf  (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf)
      #4 0x7f4a3c7ff18a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a)
      #5 0x7f4a3c7de858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858)
      #6 0x7f4a3c7de728  (/lib/x86_64-linux-gnu/libc.so.6+0x25728)
      #7 0x7f4a3c7eff35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35)
      #8 0x558f7588a913 in CScheduler::MockForward(std::chrono::duration<long, std::ratio<1l, 1l> >) scheduler.cpp:83:5
      #9 0x558f75b0e5b1 in mockscheduler()::$_7::operator()(RPCHelpMan const&, JSONRPCRequest const&) const rpc/misc.cpp:435:30
      #10 0x558f75b0e5b1 in std::_Function_handler<UniValue (RPCHelpMan const&, JSONRPCRequest const&), mockscheduler()::$_7>::_M_invoke(std::_Any_data const&, RPCHelpMan const&, JSONRPCRequest const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:285:9
      #11 0x558f7587a141 in std::function<UniValue (RPCHelpMan const&, JSONRPCRequest const&)>::operator()(RPCHelpMan const&, JSONRPCRequest const&) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14
      #12 0x558f7587a141 in RPCHelpMan::HandleRequest(JSONRPCRequest const&) const rpc/util.cpp:565:26
      #13 0x558f756c0086 in CRPCCommand::CRPCCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, RPCHelpMan (*)())::'lambda'(JSONRPCRequest const&, UniValue&, bool)::operator()(JSONRPCRequest const&, UniValue&, bool) const ./rpc/server.h:110:91
      #14 0x558f756c0086 in std::_Function_handler<bool (JSONRPCRequest const&, UniValue&, bool), CRPCCommand::CRPCCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, RPCHelpMan (*)())::'lambda'(JSONRPCRequest const&, UniValue&, bool)>::_M_invoke(std::_Any_data const&, JSONRPCRequest const&, UniValue&, bool&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:285:9
      #15 0x558f756b8592 in std::function<bool (JSONRPCRequest const&, UniValue&, bool)>::operator()(JSONRPCRequest const&, UniValue&, bool) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14
      #16 0x558f756b8592 in ExecuteCommand(CRPCCommand const&, JSONRPCRequest const&, UniValue&, bool) rpc/server.cpp:480:20
      #17 0x558f756b8592 in ExecuteCommands(std::vector<CRPCCommand const*, std::allocator<CRPCCommand const*> > const&, JSONRPCRequest const&, UniValue&) rpc/server.cpp:444:13
      #18 0x558f756b8017 in CRPCTable::execute(JSONRPCRequest const&) const rpc/server.cpp:464:13
      #19 0x558f7552457a in (anonymous namespace)::RPCFuzzTestingSetup::CallRPC(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) test/fuzz/rpc.cpp:50:25
      #20 0x558f7552457a in rpc_fuzz_target(Span<unsigned char const>) test/fuzz/rpc.cpp:354:28
      #21 0x558f7544cf0f in std::_Function_handler<void (Span<unsigned char const>), void (*)(Span<unsigned char const>)>::_M_invoke(std::_Any_data const&, Span<unsigned char const>&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300:2
      #22 0x558f75c05197 in std::function<void (Span<unsigned char const>)>::operator()(Span<unsigned char const>) const /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688:14
      #23 0x558f75c05197 in LLVMFuzzerTestOneInput test/fuzz/fuzz.cpp:74:5
      #24 0x558f753d8073 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o
      #25 0x558f753c1f72 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o
      #26 0x558f753c7d6a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o
      #27 0x558f753f3a92 in main (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x5a8a92)
      #28 0x7f4a3c7e00b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
      #29 0x558f7539cc9d in _start (/root/fuzz_dir/scratch/fuzz_gen/code/src/test/fuzz/fuzz+0x551c9d)

ACKs for top commit:
  practicalswift:
    cr ACK fa2e614

Tree-SHA512: cfa120265261f0ad019b46c426b915c1c007806b37aecb27016ce780a0ddea5e6fc9b09065fd40684b11183dcd3bf543558d7a655e604695021653540266baf7
@bitcoin-core bitcoin-core locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants