Topic: Interface Optimization (Read 9067 times)
qt-bitcoin now gives status bar notifications when a (net positive) transaction comes in:
The QT GUI is feature-complete now. Even the transaction details dialog on double-click works.
I could still use some help testing: https://github.com/laanwj/bitcoin-qt
I could still use some help testing: https://github.com/laanwj/bitcoin-qt
Rebase onto https://github.com/bitcoin/bitcoin/pull/180, add the relevant autotools options (if you can), then I'd guess it would be best to just do as you said and put res in src/qt/res or similar.
I'd welcome some testing. Nearly all the functionality of bitcoin-wx is now implemented. Although it seems to work fine, there might still be a few glitches so I recommend testing on a testnet (or testnet-in-a-box).
Also, the Qt GUI needs its own base directory in the source tree for resources such as images, icons and forms. It cannot use the bmp/xpm images from the Wx one.
Quote
Can you revert all the dir changes and rebase onto autotools.
Btw what directory layout do you recommend for the different GUIs?Also, the Qt GUI needs its own base directory in the source tree for resources such as images, icons and forms. It cannot use the bmp/xpm images from the Wx one.
- bitcoin/src/qt for the source files?
- bitcoin/src/qt/res for resources? or somewhere outside the src tree?
Can you revert all the dir changes and rebase onto autotools. As this will no doubt make it after autotools, it would be nice to have the support there as autotools is designed to handle multiple UIs already.
Yes, I'm only using qmake at the moment because it is easy to get a project running. When I feel it's mature enough I'll do the build system work. I've developed this in a separate directory structure so I can maintain it individually until it gets merged, but will conform it to whatever the bitcoin directory structure is at that time.Quote
I need to be able to see the address in order to verify that I've given someone the correct one. Please don't make them hard to find.
Of course not. They shouldn't be hard to find if you need them. It's just that a mass of 37 character long random-looking text sequences overwhelms people, and they're very hard to compare by eye (unlike user-specified labels/tags).
Although it brings the question, if you don't need to read them, why display them at all. Hmm... in the transaction overview itself, labels are already preferred by default, only if the label for an address is empty it shows the address.
I need to be able to see the address in order to verify that I've given someone the correct one. Please don't make them hard to find.
Can you revert all the dir changes and rebase onto autotools. As this will no doubt make it after autotools, it would be nice to have the support there as autotools is designed to handle multiple UIs already.
All this tagging and such is really cool, but I'd much rather see this get finished properly with no new features than add a bunch of stuff that needs backed work as well.
Agreed. Tagging would need backend changes, filtering does not.But yes as I stated before the first priority is to get it working the way it is now. I'm not an UI designer anyway. After that, Qt frontend coders/designers (much more numerous than Wx people) can give their shot at improving the interface.
Edit: still, I think it's very important that future ideas for the GUI are discussed here The GUI is people's first impression of the project, and having a more useful and user-friendly interface will help adoption.
All this tagging and such is really cool, but I'd much rather see this get finished properly with no new features than add a bunch of stuff that needs backed work as well. My suggestion: get the whole system set up to work with a UI chosen at compile time and do the whole filtering stuff and whatnot after that. Keep backend changes in a separate commit.
Maybe the tagging stuff is harder. But Changing the current tabs for a combo (select) and moving the address book and settings to a tab shouldn't be too hard.
Of course, I'm not saying a qt equivalent (as the interface is now) shouldn't be commited first.
All this tagging and such is really cool, but I'd much rather see this get finished properly with no new features than add a bunch of stuff that needs backed work as well. My suggestion: get the whole system set up to work with a UI chosen at compile time and do the whole filtering stuff and whatnot after that. Keep backend changes in a separate commit.
I like monospaced. After all, you don't need to read the addresses so legibility is not very important.
Agreed. Although it brings the question, if you don't need to read them, why display them at all. Hmm... in the transaction overview itself, labels are already preferred by default, only if the label for an address is empty it shows the address.
Maybe it would be useful to auto-assign labels to addresses?
Even "myaddress1" "myaddress2" "otheraddress1" "otheraddress2" are easier to read than "mpRURXzSnA1....", and it would encourage people to give them meaningful names.
Maybe "receiving address1" "receiving address2" "send address1" "send address2"...is more clear. Seems a good idea though. You should always be able to copy to clipboard any address.
In the client I currently have (don't know if this has been already changed) when you label an address it still shows the address. I would prefer to see only the label.
Quote
The filter of "received with" won't be very useful unless it filters the description instead of the address. Otherwise people would tend to repeat the address to receive from the same source.
It's a pity that bitcoin doesn't have "received from". It's possible to retrieve the inputs for a transaction, but there will usually be multiple, so one would have to have labelled all the input addresses to show it meaningfully in the GUI. Quote
Maybe tags are needed to filter incoming transactions?
Tags, like gmail tags? Yeah I could see uses for tagging transactions, for example, if you want to categorise your payments. In both cases (received with/received from) you would need to label/tag them. I don't use gmail tags. What I mean is that the "received with" filter won't be as useful as the "sent to" unless you can group by tags/labels. Maybe it is needed too for the "sent to" filter, since some service give you a different address each time you pay them.
This is exciting. Being free software, the bitcoin interface will end up being more usable than any bank's web service.
It will make bitcoins more valuable.
I like monospaced. After all, you don't need to read the addresses so legibility is not very important.
Agreed. Although it brings the question, if you don't need to read them, why display them at all. Hmm... in the transaction overview itself, labels are already preferred by default, only if the label for an address is empty it shows the address.
Maybe it would be useful to auto-assign labels to addresses?
Even "myaddress1" "myaddress2" "otheraddress1" "otheraddress2" are easier to read than "mpRURXzSnA1....", and it would encourage people to give them meaningful names.
Quote
I also like the idea to have a filter instead of the current tabs and leave the tabs for other things.
Interesting idea. The current tabs are filters, but kind of limited.Quote
A tab for the address book and the the button to "see transactions to/from this address" are cool.
So the idea would be to include the address book as tab in the main GUI, instead of as a separate dialog?I've thought about this too. One of the most common usecases of the GUI will be "send money to someone you already know", so having the address book available immediately is arguably useful.
Quote
The filter of "received with" won't be very useful unless it filters the description instead of the address. Otherwise people would tend to repeat the address to receive from the same source.
It's a pity that bitcoin doesn't have "received from". It's possible to retrieve the inputs for a transaction, but there will usually be multiple, so one would have to have labelled all the input addresses to show it meaningfully in the GUI. Quote
Maybe tags are needed to filter incoming transactions?
Tags, like gmail tags? Yeah I could see uses for tagging transactions, for example, if you want to categorise your payments.
I like monospaced. After all, you don't need to read the addresses so legibility is not very important.
I also like the idea to have a filter instead of the current tabs and leave the tabs for other things. A tab for the address book and the the button to "see transactions to/from this address" are cool.
The filter of "received with" won't be very useful unless it filters the description instead of the address. Otherwise people would tend to repeat the address to receive from the same source.
Maybe tags are needed to filter incoming transactions?
I also like the idea to have a filter instead of the current tabs and leave the tabs for other things. A tab for the address book and the the button to "see transactions to/from this address" are cool.
The filter of "received with" won't be very useful unless it filters the description instead of the address. Otherwise people would tend to repeat the address to receive from the same source.
Maybe tags are needed to filter incoming transactions?
By the way, what's the thought about fonts for bitcoin addresses? Monospaced or variable-width? I'm not entirely sure
If you have a list of addresses, like in the address book, they look kind of ugly as they are not lined up.
Variable-width:
Versus monospace:
If you have a list of addresses, like in the address book, they look kind of ugly as they are not lined up.
Variable-width:
Versus monospace:
The top bar is there purely for convenience, so that it's possible to easily copy/paste your address somewhere. It could be hidden, but that could confuse people in another way: where do I find my own address?
I think by simply adding some tooltips it could be documented better, that generating a new address doesn't throw away your old one, etc.
I think by simply adding some tooltips it could be documented better, that generating a new address doesn't throw away your old one, etc.
Perhaps replacing the address bar with a [New receiving address] button would be sufficient. Of course, a tab listing all addresses (used and 'hidden') would also help demystify the addresses hidden in the keypool.
There is such a tab in "Address Book", "Receiving addresses". It shows all your addresses.
I wonder if "Your receiving address" bar is necessary. I suppose it is supposed to encourages the use of a new address with every transaction, but I would guess most people do not do that (consider how many people have a bitcoin address in their forum signature). In fact, the 'address bar' gave me the impression that the initial address was my ONLY address and I became very confused when it changed. I thought I lost my recently received coins!
Perhaps replacing the address bar with a [New receiving address] button would be sufficient. Of course, a tab listing all addresses (used and 'hidden') would also help demystify the addresses hidden in the keypool.
Perhaps replacing the address bar with a [New receiving address] button would be sufficient. Of course, a tab listing all addresses (used and 'hidden') would also help demystify the addresses hidden in the keypool.
I've been pretty silent on this, but work has continued. Most was ground work thinking out what is the best way to bind the GUI to bitcoin core, but at least it now displays the actual transactions and statistics (and in addition to the original client, has sortable columns by clicking on the headers). Things I still need to do to make it functional;
Lower priority:
Future:
implemented
Refresh transaction list when new blocks came in (requires a restart now
)Sending coinsShow error messages/alerts from core- More thorough testing of the view with all the kinds of transactions (sendmany, generation)
Lower priority:
Fix address book editorFix options editorShow transaction details
Future:
- Separation of data types from core, so that it works through the API as well as in-process
Do you have a Bitcoin address where we can post donations? I was actually thinking of creating a bounty for a Qt port of the GUI, but you already created one 
Yeah I do: see signature Do you have a Bitcoin address where we can post donations? I was actually thinking of creating a bounty for a Qt port of the GUI, but you already created one
Jump to: