Bitcoin-Qt, the future Bitcoin client GUI [user input needed]

[flower1024]

if your interested in some help for a german translation: PM me

Do you have Russian translation? If not, you are welcome to contact me

There are currently the following translations in src/qt/locale:

• bitcoin_de.ts
• bitcoin_nl.ts
• bitcoin_ru.ts

The Russian one is mostly up to date (except for wallet encryption, which I committed today). The German and Dutch ones are pretty much outdated and really need to be looked at.

german translation is completed right now (github fork flower1024); but untested. i'll do that tonight.

have you read this: https://bitcointalk.org/index.php?topic=19168.msg240196#msg240196
in germany 0,005 is a natural way to write down numbers (and its not 5). i did not check it yet; but would be nice if you just take the system locale to interpret numbers.

[1714116597]

1714116597

[1714116597]

1714116597

[1714116597]

1714116597

[1714116597]

1714116597

[1714116597]

1714116597

[1714116597]

1714116597

[aq]

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well

[wumpus]

have you read this: https://bitcointalk.org/index.php?topic=19168.msg240196#msg240196
in germany 0,005 is a natural way to write down numbers (and its not 5). i did not check it yet; but would be nice if you just take the system locale to interpret numbers.

This was taken into account; when entering coin amounts the whole amount and decimals are separate fields, so you can never make a mistake with that. Both ',' and '.' take you to the decimals field.

For displaying the US locale is always used. This was by choice (is the same in the original UI).

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well

Yeah, good point, that'd make sense... it'd have to remember the old number of blocks.

[kjj]

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well

The problem with this is that the chain doesn't have an end.  It doesn't even have a current endpoint.  All it has is the dividing line between blocks that your node knows about, and blocks that it doesn't know about yet.  It seems like a trivial thing, but the misunderstanding can have serious consequences.

But yeah, the progress bar could be better.  But you can't make it too good, or it will confuse users.  There is even a trope about it.

Using the last known block height like you suggest seems like a good way to do it.

[aq]

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well

The problem with this is that the chain doesn't have an end.  It doesn't even have a current endpoint.  All it has is the dividing line between blocks that your node knows about, and blocks that it doesn't know about yet.  It seems like a trivial thing, but the misunderstanding can have serious consequences.

But yeah, the progress bar could be better.  But you can't make it too good, or it will confuse users.  There is even a trope about it.

Using the last known block height like you suggest seems like a good way to do it.

All academical discussions beside, the progress bar is shown right now, but stays at 99% for almost all users once a day for about a minute. It is only shown while downloading blocks and it is hidden when the current block count is reached. So it is effectively a static image. My "proposal" would make it usable. And the progress bar is not a scientific measurement device, it is only a visual feedback, so that the user can see that something is being download. In fact stating 99% all the time, the is indistinguishable  between some download is happening and nothing is being downloaded.

[Maged]

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well

To prevent a massive amount of support requests if you add this, be sure not to use this behavior until the client thinks that they've completed the initial download of blocks. Otherwise, if someone turns off their client in the middle of the initial download, they might think that the client restarted the download instead of continuing it. However, you'd also then need to visually differentiate progress between the initial download and updates. (different progress bar color?)

[Pieter Wuille]

What about persistently storing the last block number at which the client was in sync with the network? Initially this is zero, and it remains zero until the client is entirely up-to-date. If at that point it goes offline, and comes back after having missed a few blocks, a new progress bar appears that represents the catching up from that previous point to the current blockchain tip.

[wumpus]

Sounds like a lot of hassle. Different progress bar colors complicate stuff for both the user and developer :-) The progress bar was meant to show initial block chain download progress, so you're right that it might be better to keep it at that.

Probably, we should simply not show the progress bar if progress is so close to 100% at startup... The spinner shows that it is catching up to the block chain, anyway.

[aq]

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well

To prevent a massive amount of support requests if you add this, be sure not to use this behavior until the client thinks that they've completed the initial download of blocks. Otherwise, if someone turns off their client in the middle of the initial download, they might think that the client restarted the download instead of continuing it. However, you'd also then need to visually differentiate progress between the initial download and updates. (different progress bar color?)

BTW, a simple "resuming" in the syn text would prevent all your massive support requests.
It depends on what the progress bar displays. Does it display the amount of work (download) that has to be done, or does it display the current state (now at block n of m). If it always if the former, it would be OK for the user, because it displays what the progress of the *current* work, in contrast to displaying the combined work over all program starts.
For example, when I copy some files, the progress bar goes from 0 to 100% - it does not include all files I ever copied
Different colors? Now *that* would trigger some massive amount of support requests, maybe even I would ask what this is all about.

[wumpus]

It depends on what the progress bar displays. Does it display the amount of work (download) that has to be done, or does it display the current state (now at block n of m). If it always if the former, it would be OK for the user, because it displays what the progress of the *current* work

It displays the part of the total block chain that has been downloaded. It's comparable to re-starting a torrent client, or other download client. If it would start from 0% every time a user might indeed assume it has restarted.

Then again, as bitcoin is not regarded as a download client, probably this discussion is completely theoretic and users would not complain if it showed only the (relative) part of what still has to be downloaded... also, you get the "m out of n blocks downloaded" in a tooltip which shows absolute numbers...

[Matoking]

I compiled the latest version (commit 4785e6df74151f91d0c1) for Windows.

http://www.mediafire.com/?rfawsiajyfy70kk

I'll probably look at the code and try my hands on the GUI and try fixing things (for instance, minimizing the application makes the application go blank, you have to click the icon on system tray to fix it)

On Windows the window's (pun not intended) background should be made plain white when the window is maximized, since otherwise it's very hard to read (black text on almost black background).

Minimizing the window makes the application window go blank when you try opening it again from the taskbar instead of system tray. Or maybe the application should just go to system tray (in same manner as "closing" the application)

EDIT :
I fixed a few things on my fork here :
https://github.com/Matoking/bitcoin-qt

It should fix the "window becoming empty when minimized and then brought up from taskbar again" issue and make the window background plain when it's maximized on Windows (makes it more readable).

Compare this (before)
https://i.imgur.com/crwHo.png
to this (after)
https://i.imgur.com/MShYj.png

Feel free to add to the main repository if I didn't break anything.

[wumpus]

I compiled the latest version (commit 4785e6df74151f91d0c1) for Windows.

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

Maybe even make a little website to download from... I might have a spin at it when I have some time, though I'm not really a web designer.

[aq]

I fixed a few things on my fork here :
https://github.com/Matoking/bitcoin-qt

It should fix the "window becoming empty when minimized and then brought up from taskbar again" issue and make the window background plain when it's maximized on Windows (makes it more readable).

Compare this (before)
https://i.imgur.com/crwHo.png
to this (after)
https://i.imgur.com/MShYj.png

Great enhancement!
While you are already at it, would it be possible to make this transparent thing optional. I mean if you have some dark window (ie. command line) behind the bitcoin window, it has the same problem as if it would be maximized. IMO this transparent effect doesn't fit a financial software anyway. So again IMO, this option should be disabled by default, but maybe thats just me.
Yes, I know, should code this myself

[Gavin Andresen]

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

[aq]

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

Doesn't bitcoin-qt already contain the 0.4 core? If yes, what is the reason to even release bitcoin 0.4? Why not release 0.4-qt instead?

[twobits]

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

Doesn't bitcoin-qt already contain the 0.4 core? If yes, what is the reason to even release bitcoin 0.4? Why not release 0.4-qt instead?

I would think they should be released a separately as the qt dependency  changes the nature of the licenses being depended on, and a more free main branch would be preferable.

[FatherMcGruder]

I would think they should be released a separately as the qt dependency  changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

[twobits]

I would think they should be released a separately as the qt dependency  changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

It is just that.   It would be the most restrictive license yet used for anything required.   If this was  brought in,   anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it.   Wxwidgets made sure those conditions did not apply to derived works distributed in binary form.   The creators of Qt got dragged a bit towards it even being  as unrestricted as the LGPL in the beginning.  I had noticed that the licenses picked so far are all much less restrictive  and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL

[zwierzak]

One thing which should be change before merge! Progressbar which inform about sync process should be like in Bitcoin Wallet for Android. This mean that 0% is than, when we run client and it is unsynchronized. Now it shows 99% after start and it not changing until full synchronization. This is not functional if not inform about progress.

[Pieter Wuille]

I would think they should be released a separately as the qt dependency  changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

It is just that.   It would be the most restrictive license yet used for anything required.   If this was  brought in,   anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it.   Wxwidgets made sure those conditions did not apply to derived works distributed in binary form.   The creators of Qt got dragged a bit towards it even being  as unrestricted as the LGPL in the beginning.  I had noticed that the licenses picked so far are all much less restrictive  and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL

But the license of the bitcoin and bitcoin-qt code is still MIT, even though it links against an LGPL library. IANAL, but I believe this means that if you use the source to build a headless version (which doesn't link against Qt) there is no restriction on the distribution of the resulting binary.