[Qt] Add spend all button to the SendCoinsDialog #11098

pull CryptAxe wants to merge 1 commits into bitcoin:master from CryptAxe:spendall changing 5 files +48 −0
  1. CryptAxe commented at 6:27 AM on August 20, 2017: contributor
  2. [Qt] Add spend all button to the SendCoinsDialog
    Get the balance of the wallet (with CoinControl if enabled).
    Then divide the amount available by all of the SendCoinEntry(s) and
    check the subtract fee from amount checkbox for all SendCoinEntry(s).
    89e9edacbf
  3. fanquake added the label GUI on Aug 20, 2017
  4. meshcollider commented at 12:46 PM on August 20, 2017: contributor

    I don't like the dividing equally between outputs behaviour, I think the button should only be possible on single entry spends, makes little sense to me otherwise. From discussion in #11033, @laanwj didn't just want a button added for appearance reasons. Also nits, please update to snake_case and modify braces as per style guideline.

  5. CryptAxe commented at 7:54 PM on August 20, 2017: contributor

    I don't like the dividing equally between outputs behaviour, I think the button should only be possible on single entry spends, makes little sense to me otherwise.

    Don't use the button with multiple outputs if you don't like it, no reason to stop other people from dividing their balance between multiple recipients. The way the SendCoinsDialog works right now assumes that there can be any number of recipients.

    From discussion in #11033, @laanwj didn't just want a button added for appearance reasons.

    Feel free to suggest a better option. I put the button in an area so that it doesn't take up any vertical space and mess up the appearance of the entire page. It would be possible to put something on the SendCoinEntry(s) instead and send a signal to the SendCoinsDialog instance for example but that was more cluttered visually and in code when I tried it.

    Also nits, please update to snake_case and modify braces as per style guideline.

    You'll have to point out where you want me to use snake case...

  6. promag commented at 9:48 PM on August 20, 2017: member

    You'll have to point out where you want me to use snake case...

    See developer notes.

  7. CryptAxe commented at 3:02 AM on August 21, 2017: contributor

    The best assumption that I can make from your response is that you want me to use snake case for variable names. I see that is in the developer notes now, but it is certainly not in line with most of the code that I see in Bitcoin core. Am I correct that we are now going to diverge from the style in the existing codebase, and require all new code to look different, creating a big mess of many different styles?

    I don't know how much value a style guideline has besides maintaining clarity and uniformity of code, aren't we throwing that out the window here?

  8. achow101 commented at 2:13 PM on August 21, 2017: member

    @CryptAxe Yes, use snake case for all new code. Please follow the developer guidelines for all new code, regardless of the style currently in the codebase. Since the codebase changes a lot, the style of the codebase will shift over to the new style as things are changed and replaced.

  9. CryptAxe commented at 10:18 PM on August 21, 2017: contributor

    Why snake case, what led to that change? Who even made this decision and why would we diverge from the existing code in the first place? If this rule is followed we are making Bitcoin's code worse, it will be a mix of several styles (the new one being especially ugly in my opinion). The point of style guidelines are to maintain clarity and uniformity. There is no reason for Bitcoin to have style guidelines if they are going to change all the time. Do we really think 100% of the codebase is going to be re-written in the new style, or is it more likely that we will end up with an ugly mess as a result of this?

    Also I'm not trying to roast anyone who has commented here, I'm addressing the broader developer community with my questions..

  10. promag commented at 10:27 PM on August 21, 2017: member

    Why snake case, what led to that change? Who even made this decision and why would we diverge from the existing code in the first place?

    Some group of people did, git blame can point you in the right direction. But who cares, for me consistency wins.

    Do we really think 100% of the codebase is going to be re-written in the new style

    Eventually.

    or is it more likely that we will end up with an ugly mess as a result of this?

    I guess it is a mess because of the early lack of rules to follow and time to enforce those rules. Even nowadays, there is lot of new code that doesn't met those rules.

  11. jonasschnelli commented at 5:32 PM on September 7, 2017: contributor

    Concept ACK. I think the send all button needs to be in the send-to-box context (not in the global). Ideally close to where you enter the amount (it's mostly related to that IMO).

    I think it should be [amount] [denomination] [send-all] [subtract-from-amount].

    Maybe we should call it not send-all because the max amount may change after you have pressed the button == you no longer sending "all". Maybe something like "select all", or "use max available" makes more sense.

    <img width="1067" alt="bildschirmfoto 2017-09-07 um 10 28 10" src="https://user-images.githubusercontent.com/178464/30176575-c43a67f6-93b7-11e7-8c2c-ec8b2156f820.png">

  12. CryptAxe commented at 7:06 PM on September 7, 2017: contributor

    Do you think a checkbox would be good for that? It looked a bit weird having two of them next to eachother. I can't come up with anything prettier besides a QLable with an icon people can click on, but we would need to add an icon.

    On Sep 7, 2017 10:33 AM, "Jonas Schnelli" notifications@github.com wrote:

    Concept ACK. I think the send all button needs to be in the send-to-box context (not in the global). Ideally close to where you enter the amount (it's mostly related to that IMO).

    I think it should be [amount] [denomination] [send-all] [subtract-from-amount].

    Maybe we should call it not send-all because the max amount may change after you have pressed the button == you no longer sending "all". Maybe something like "select all", or "use max available" makes more sense.

    [image: bildschirmfoto 2017-09-07 um 10 28 10] https://user-images.githubusercontent.com/178464/30176575-c43a67f6-93b7-11e7-8c2c-ec8b2156f820.png

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/11098#issuecomment-327869628, or mute the thread https://github.com/notifications/unsubscribe-auth/AHu1Ntv3bIPNHOe5zfA5y35LPhibq5xdks5sgCjZgaJpZM4O8iEI .

  13. meshcollider commented at 2:36 AM on September 8, 2017: contributor

    What's wrong with using a button like you're currently doing? Why are you talking about a checkbox?

  14. CryptAxe commented at 2:54 AM on September 8, 2017: contributor

    Well I can but adding a push button where Jonas has the arrow pointing would take up more vertical space and mess up the layout a bit. Should I make some screenshots showing different options?

    On Sep 7, 2017 7:37 PM, "MeshCollider" notifications@github.com wrote:

    What's wrong with using a button like you're currently doing? Why are you talking about a checkbox?

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/11098#issuecomment-327983132, or mute the thread https://github.com/notifications/unsubscribe-auth/AHu1NuAHIwuGVjPsnlTA719fJ9OSWAtKks5sgKiAgaJpZM4O8iEI .

  15. promag commented at 7:59 AM on September 8, 2017: member

    Maybe something like "select all", or "use max available" makes more sense

    Agree with @jonasschnelli, and that "button" should fill the amount field and toggle the checkbox. And I think it works well with multiple outputs: So when pressed the amount field will have the available amount minus other input amounts.

  16. MarcoFalke referenced this in commit 22cdf93c06 on Nov 10, 2017
  17. CryptAxe commented at 12:11 AM on November 17, 2017: contributor

    #11316 which improved this was merged so I'll close it.

  18. CryptAxe closed this on Nov 17, 2017

  19. PastaPastaPasta referenced this in commit 39fdbac96a on Dec 27, 2019
  20. PastaPastaPasta referenced this in commit acc0f7163b on Jan 2, 2020
  21. PastaPastaPasta referenced this in commit 7850cc6926 on Jan 4, 2020
  22. PastaPastaPasta referenced this in commit e6d244e955 on Jan 12, 2020
  23. PastaPastaPasta referenced this in commit d1c3110166 on Jan 12, 2020
  24. PastaPastaPasta referenced this in commit 561cbe1c88 on Jan 12, 2020
  25. PastaPastaPasta referenced this in commit 0d189d7264 on Jan 12, 2020
  26. PastaPastaPasta referenced this in commit b88472a600 on Jan 12, 2020
  27. PastaPastaPasta referenced this in commit 1c28dbf923 on Jan 12, 2020
  28. PastaPastaPasta referenced this in commit fbba658678 on Jan 16, 2020
  29. PastaPastaPasta referenced this in commit 99a31400e4 on Jan 22, 2020
  30. PastaPastaPasta referenced this in commit bb43baf7c4 on Jan 22, 2020
  31. PastaPastaPasta referenced this in commit 12550fc988 on Jan 29, 2020
  32. PastaPastaPasta referenced this in commit 1510c749d8 on Jan 29, 2020
  33. ckti referenced this in commit 665174082c on Mar 28, 2021
  34. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-13 21:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me