Topic: Bitcoin-Qt, the future Bitcoin client GUI [user input needed] - page 8. (Read 57134 times)
Please do accept u if it ever comes up for input.
Configurable units (BTC/uBTC/mBTC) are on the way, for the people that like to see large numbers 
BTW is anyone interested in helping build binary packages (linux) / installers (windows)?
BTW is anyone interested in helping build binary packages (linux) / installers (windows)?
Based on some patches made to the main client and forks this are some ideas to implement:
-Import Keys
-Determine where the .dat and important files would be located
-Deterministic wallets generated with a strong password. No need to store the keys in the wallet.dat(16+ chars cap and uncap, numbers, and symbols)
-Vanity Generator, Miner, and bulk key generation.(Under a certain folder x ammount of keys)
-Show addresses already "linked" together in groups.
-Advanced Send(From, to, both with multiple inputs/outputs and a specific fee)
-Access control for the API, create users who can only manage specific accounts and/or limited commands.
Most of those are not really UI features but backend, you're better of lobbying for them for the core client. I think a some of them are already available as pull requests (such as deterministic wallets). -Import Keys
-Determine where the .dat and important files would be located
-Deterministic wallets generated with a strong password. No need to store the keys in the wallet.dat(16+ chars cap and uncap, numbers, and symbols)
-Vanity Generator, Miner, and bulk key generation.(Under a certain folder x ammount of keys)
-Show addresses already "linked" together in groups.
-Advanced Send(From, to, both with multiple inputs/outputs and a specific fee)
-Access control for the API, create users who can only manage specific accounts and/or limited commands.
My project mostly focuses on the UI and improving the core <-> UI communication.
hey, why don't you use this quite beautiful iconset, which has virtually every icon you can think of (7600!!):
http://www.famfamfam.com/lab/icons/silk/
Creative Commons Attribution 2.5 License, and the guy specifies that he has to be mentioned only on the credits page...
I think the problem with that icon set was that it only has 16x16 icons, which are good for some purposes, but not (for example) for the toolbar in many window systems. http://www.famfamfam.com/lab/icons/silk/
Creative Commons Attribution 2.5 License, and the guy specifies that he has to be mentioned only on the credits page...
But feel free to replace some of the small icons if you think they have better icons than the current ones (icons are in src/qt/res/icons..)
hey, why don't you use this quite beautiful iconset, which has virtually every icon you can think of (7600!!):
http://www.famfamfam.com/lab/icons/silk/
Creative Commons Attribution 2.5 License, and the guy specifies that he has to be mentioned only on the credits page...
http://www.famfamfam.com/lab/icons/silk/
Creative Commons Attribution 2.5 License, and the guy specifies that he has to be mentioned only on the credits page...
Not really an alternative client, but an alternative GUI for the original bitcoin client
Hi...
in Windows...
for Miners...
"bitcoin.exe -server"
would be very usefull to see all ip miners connected to the server, with total Mh/s.
Thanks.
Something that I see lacking in the main client is to be able to determine a fee on the fly instead of going trough the preferences to change it and return it to normal.
I am all in for the folder structure.
Based on some patches made to the main client and forks this are some ideas to implement:
-Import Keys
-Determine where the .dat and important files would be located
-Deterministic wallets generated with a strong password. No need to store the keys in the wallet.dat(16+ chars cap and uncap, numbers, and symbols)
-Vanity Generator, Miner, and bulk key generation.(Under a certain folder x ammount of keys)
-Show addresses already "linked" together in groups.
-Advanced Send(From, to, both with multiple inputs/outputs and a specific fee)
-Access control for the API, create users who can only manage specific accounts and/or limited commands.
For usability make a divide between: Power Users/Simple Users.
Power Users have low level access(Many of the futures described above)
Simple users are limited to tx historial/contacts/send and status/messages dumb down.
Will help as I can when I get my Ubuntu box set up again.
I am all in for the folder structure.
Based on some patches made to the main client and forks this are some ideas to implement:
-Import Keys
-Determine where the .dat and important files would be located
-Deterministic wallets generated with a strong password. No need to store the keys in the wallet.dat(16+ chars cap and uncap, numbers, and symbols)
-Vanity Generator, Miner, and bulk key generation.(Under a certain folder x ammount of keys)
-Show addresses already "linked" together in groups.
-Advanced Send(From, to, both with multiple inputs/outputs and a specific fee)
-Access control for the API, create users who can only manage specific accounts and/or limited commands.
For usability make a divide between: Power Users/Simple Users.
Power Users have low level access(Many of the futures described above)
Simple users are limited to tx historial/contacts/send and status/messages dumb down.
Will help as I can when I get my Ubuntu box set up again.
Very cool! Too bad I only took a year of C++ 
Nice, though I would move the "Add recipient" and "Send" buttons out of the scrollarea, so that they are always visible, just like on the address book page. 
Yes good idea, doneAlso the fourth bar should be green and not yellow
Lol, I agree, feel free to modify the image. I suppose this also means that the inbetween-bars should be yellow/orange instead of red to make sure it's still a nice gradient.
Done! And the "updating" icon is animated now.
Nice, though I would move the "Add recipient" and "Send" buttons out of the scrollarea, so that they are always visible, just like on the address book page.
The connection status indicator could display some additional information in the tooltip that there are connection problems if there are 8 or less connections/all connections are outgoing, kinda like a lot of BitTorrent clients already do:
Maybe that would cause more users behind NAT/firewalls to forward port 8333 and/or use upnp.
Also the fourth bar should be green and not yellow
I love the crowdsourcing going on here.
I use a very minimal X environment (I only have libs installed that are necessary for Firefox, gimp, and what's needed for scrotwm) & even though this is KDE/Qt, watching it come to life rocks.
It's Qt, but has no dependencies on KDE I use a very minimal X environment (I only have libs installed that are necessary for Firefox, gimp, and what's needed for scrotwm) & even though this is KDE/Qt, watching it come to life rocks.
But indeed, looks like this project is going in the right direction.Edit: The recipients should probably be put in some kind of vertically scrollable area. Right now the window resizes when adding more and more recipients, until it is bigger than the screen
Done! And the "updating" icon is animated now.
Is that really how the keypool works? I was under the impression that the keypool always maintains a constant number of keys (default 100). So when the user requests a new receiving address, the OLDEST key is taken from the pool and presented to the user, and a NEW key is generated and added to the pool, so that there are always 100 keys in the pool.
Hmm. I think you are right. And I agree with the earlier poster now that there needs to be an animated icon when not up to date, "3 days ago" doesn't show that it is working to get more recent data.
Maybe? I think it's a big flaw that the program generates 100 keys at a time and the user is just to guess when this happens.
It would really help people know that a new backup is needed! Hate to lose some BTC on that 101 key!!
It would really help people know that a new backup is needed! Hate to lose some BTC on that 101 key!!
Is that really how the keypool works? I was under the impression that the keypool always maintains a constant number of keys (default 100). So when the user requests a new receiving address, the OLDEST key is taken from the pool and presented to the user, and a NEW key is generated and added to the pool, so that there are always 100 keys in the pool.
Also every time I check this thread bitcoin-qt is looking better and better, thanks for working on this JohnSmith!
We only need to think of more stuff to add to the home tab, it looks a little empty at the moment.
Edit: The recipients should probably be put in some kind of vertically scrollable area. Right now the window resizes when adding more and more recipients, until it is bigger than the screen
I love the crowdsourcing going on here.
I use a very minimal X environment (I only have libs installed that are necessary for Firefox, gimp, and what's needed for scrotwm) & even though this is KDE/Qt, watching it come to life rocks.
I use a very minimal X environment (I only have libs installed that are necessary for Firefox, gimp, and what's needed for scrotwm) & even though this is KDE/Qt, watching it come to life rocks.
I agree it's useful to be able to request that number (num spare keys in key pool), but displaying that in a sensible way would be difficult. I've reserved the 'key/lock' symbols in the status bar already for wallet encryption. Until exporting/back-upping is part of the client, it'd be better off in some advanced information pane. It shouldn't overwhelm new users until they know where it's for.
And I agree with the earlier poster now that there needs to be an animated icon when not up to date, "3 days ago" doesn't show that it is working to get more recent data.
And I agree with the earlier poster now that there needs to be an animated icon when not up to date, "3 days ago" doesn't show that it is working to get more recent data.
Edit: Never mind. I misunderstood the keypool a little bit.
If it's derived from a GPL icon it's also GPL. For some of the other icons I've also used GPL icon sets (crystal SVG and friends). As long as it can be used in open source software it's OK for now.
Public domain is ofc best but it's almost impossible to find good looking public domain icons.
Ah good. I looked it up and it is part of Humanity icon theme. GPL. Use it if you want! Public domain is ofc best but it's almost impossible to find good looking public domain icons.
If it's derived from a GPL icon it's also GPL. For some of the other icons I've also used GPL icon sets (crystal SVG and friends). As long as it can be used in open source software it's OK for now.
Public domain is ofc best but it's almost impossible to find good looking public domain icons.
Public domain is ofc best but it's almost impossible to find good looking public domain icons.
Sendmany support is committed now. The whole sending layer was refactored, so please help testing
Jump to: