Bitcoin Forum
December 06, 2016, 09:54:58 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 »  All
  Print  
Author Topic: Bitcoin-Qt, the future Bitcoin client GUI [user input needed]  (Read 52446 times)
flower1024
Hero Member
*****
Offline Offline

Activity: 868


luck is just a share away


View Profile
August 31, 2011, 12:28:56 PM
 #201


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 Smiley

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.
1481061298
Hero Member
*
Offline Offline

Posts: 1481061298

View Profile Personal Message (Offline)

Ignore
1481061298
Reply with quote  #2

1481061298
Report to moderator
1481061298
Hero Member
*
Offline Offline

Posts: 1481061298

View Profile Personal Message (Offline)

Ignore
1481061298
Reply with quote  #2

1481061298
Report to moderator
1481061298
Hero Member
*
Offline Offline

Posts: 1481061298

View Profile Personal Message (Offline)

Ignore
1481061298
Reply with quote  #2

1481061298
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481061298
Hero Member
*
Offline Offline

Posts: 1481061298

View Profile Personal Message (Offline)

Ignore
1481061298
Reply with quote  #2

1481061298
Report to moderator
1481061298
Hero Member
*
Offline Offline

Posts: 1481061298

View Profile Personal Message (Offline)

Ignore
1481061298
Reply with quote  #2

1481061298
Report to moderator
1481061298
Hero Member
*
Offline Offline

Posts: 1481061298

View Profile Personal Message (Offline)

Ignore
1481061298
Reply with quote  #2

1481061298
Report to moderator
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
August 31, 2011, 01:28:54 PM
 #202

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 Wink

wumpus
Hero Member
*****
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
August 31, 2011, 03:00:00 PM
 #203

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 Wink
Yeah, good point, that'd make sense... it'd have to remember the old number of blocks.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
August 31, 2011, 03:02:53 PM
 #204

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 Wink

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
August 31, 2011, 03:21:41 PM
 #205

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 Wink

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
Legendary
*
Offline Offline

Activity: 1260


View Profile
August 31, 2011, 06:53:00 PM
 #206

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 Wink
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
Legendary
*
Offline Offline

Activity: 1036


View Profile WWW
August 31, 2011, 07:37:55 PM
 #207

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
wumpus
Hero Member
*****
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
September 01, 2011, 08:26:07 AM
 #208

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
September 01, 2011, 05:35:32 PM
 #209

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 Wink
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 Wink
Different colors? Now *that* would trigger some massive amount of support requests, maybe even I would ask what this is all about.
wumpus
Hero Member
*****
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
September 02, 2011, 02:30:03 PM
 #210

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...

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Matoking
Sr. Member
****
Offline Offline

Activity: 352

Firstbits: 1m8xa


View Profile WWW
September 03, 2011, 12:38:00 PM
 #211

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)
http://i.imgur.com/crwHo.png
to this (after)
http://i.imgur.com/MShYj.png

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

BTC : 1CcpmVDLvR7DgA5deFGScoNhiEtiJnh6H4 - LTC : LYTnoXAHNsemMB2jhCSi1znQqnfupdRkSy
Bitcoin-otc
BitBin - earn bitcoins with your pastes!
wumpus
Hero Member
*****
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
September 04, 2011, 08:23:30 AM
 #212

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
September 05, 2011, 05:32:12 PM
 #213

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)
http://i.imgur.com/crwHo.png
to this (after)
http://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
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
September 05, 2011, 08:55:55 PM
 #214

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...

How often do you get the chance to work on a potentially world-changing project?
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
September 07, 2011, 01:21:11 AM
 #215

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
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
September 07, 2011, 01:39:33 AM
 #216

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
Sr. Member
****
Offline Offline

Activity: 322



View Profile WWW
September 07, 2011, 01:42:30 PM
 #217

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?

Use my Trade Hill referral code: TH-R11519

Check out bitcoinity.org and Ripple.

Shameless display of my bitcoin address:
1Hio4bqPUZnhr2SWi4WgsnVU1ph3EkusvH
twobits
Sr. Member
****
Offline Offline

Activity: 336

Firstbits: 1a6taw


View Profile
September 07, 2011, 08:24:37 PM
 #218

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
Newbie
*
Offline Offline

Activity: 24



View Profile WWW
September 07, 2011, 09:47:25 PM
 #219

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
Legendary
*
Offline Offline

Activity: 1036


View Profile WWW
September 08, 2011, 07:59:07 AM
 #220

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!