Topic: Bitcoin-Qt, the future Bitcoin client GUI [user input needed] - page 11. (Read 57177 times)

This doesn't make sense. Why is that code generated in a Qt version that doesn't support it?

I cannot put #ifdefs in generated code, obviously, so I don't see a way to solve this :/

Seems the problem is more common, it results from a mixup between uic version and Qt header version:
http://permalink.gmane.org/gmane.comp.kde.users.kdevelop/6629

Edit: I'll move all setPlaceholderText to application code instead of .ui scripts so I can guard them with #ifdef...

Hello John,

thanks for your comments.


Regarding the build instructions: you can remove "libboost-all-dev" as it was meant as an alternative to installing the smaller packages. -all-dev includes them.

I pulled your changes but it doesn't compile because of another occurence of setPlaceholderText in the file ui_sendcoinsdialog.h generated from sendcoinsdialog.ui (addAsLabel).

Can't wait to see an installer for Windows for this GUI. It looks great.

Some suggestions:
- Add sendmany support
- Make it possible to select the sender address.
- Import/Export single addresses (for merging wallets)
- Require a password to open a wallet (encrypted wallet)
- Require a password to make a transaction
- Add a button that converts the balance to a pre-selected currency
- Option to delete an address (for the sake of overview, or don't auto-create them)
- Make it a light client (download headers only, not the complete chain)
- Display the label instead of the address in the main list

I'm aware that some suggestions belong more to the core development; but if at some point those two projects are merged, the GUI would have already taken care for that.

Clearly I'm a linux noob, is there a way for this to be on Windows? If I see this right, Qt is the same language used for Nokia apps? Thanks!

Thanks,
Indeed, and Qt looks native on both Gnome and KDE.
I've pitched CMake in the mailing list. I wonder what the reply will be \o/ Some people might be annoyed though because they went through all the trouble to port it to autotools which is no small feat. On the other hand, Mac/Windows was problematic with autotools.
This sounds like a good plan. I've renamed "Receiving addresses" to "Receive coins". The explanation at the top of the "Receiving addresses" tab should already be a guide to what people should do.
Yes it may be wise to add some one-time warnings/popups for such things.
The "hidden address" thing using a flag is a good idea, both for receiving and sending addresse (for the reasons that you mention). We'd have to be really sure that this is safe, though. I'll have to think about it a bit.

Also, there'd be no way to recover an address once deleted, unless we also add a "Show all addresses" tick.
I think so. I don't really understand the default receiving address stuff either. I don't think it's used anywhere in the Bitcoin core code. I need to check this and if that's the case, completely nuke it.
It's read-only, so you can see it and copy/paste it. Granted, it could be replaced with a plain label, or made disabled instead of read-only.
Yeah...
It should indeed check addresses for validity before adding to address book.
The checkbox is indeed unnecessary. Leaving the label field empty could accomplish the same.
I'll update the instructions... I've also changed the placeholders to only be compiled for Qt 4.7+.

Me again ...  

I was thinking more about the sending addresses in the address book and I identified two use-cases that need a different handling:

A.) In my address book I want to have addresses of my other wallets, of my girlfriend, my children, etc. I can send coins to them repeatedly and I see whom I've sent coins to in the transaction list.

B.) I'm buying something with my coins. I'm getting an address for this transaction. I will never need it again -> it shouldn't show up in the address book. But still, I want to see in the transaction list, what I spent those coins for!

This could be implemented using the same "hidden" flag as proposed for the receiving addresses.

I'm curious to read your comments.

Hello John, hello everybody!

I found this thread a few days ago and finally had the time to build it and try it (on testnet). I'm trying to dump all my thoughts about it here ... sorry for being so unorganized.

1.) John & Co: thanks for doing this. I think the bitcoin-community is now huge enough to deserve a better GUI 
2.) Even though I'm a Gnome user I think Qt is the right choice for the GUI, it's relatively high-level and allows to write readable code. And the platfom-support is very good.
3.) I'm not that experienced with build-systems but my colleages advised me to only use autotools if it's really necessary or you are already fluent in using them, otherwise there are less frustrating options, cmake was mentioned explicitly; autotools was called obsolete. Maybe we should ask the core developers, why they want to use autotools and if they considered alternatives.
4.) Like others here, I also welcome the removal of this irritating "Your bitcoin address:" section, the solution here is better. But I think it's still suboptimal, because of the redundancy between address book and receiving addresses. My proposal: remove "receiving addresses" and add "Receive coins" right next to "Send coins". When the user clicks "Receive coins" you show a pop-up saying [1] "Your wallet may have an unlimited amount of receiving addresses. It's recommended to hand out a different address to everyone sending you coins, because the address is usually the only way to determine who sent you the coins. You might even want to create a new address for every transaction. Addresses are never deleted, although you may delete it from the address book, if you don't plan to use it anymore. If you later receive coins to a hidden address it will show again in the address book automatically.". Below is a checkbox "Don't show again" and an OK-button which brings you right to the receiving tab of the address book.
5.) Like mentioned in 4.) I'd like to have the delete button activated with a tooltip "Delete the selected address from the address book. You will still be able to receive coins to this address". It's clear to me that this new workflow will need a change in the backend, namely having the possibility to set an address record as "hidden" in the database. But IMHO this is worth the change.
6.) I think the "Set as default receiving address" is obsolete now? If not, please tell me what it does. (And it probably should be disabled by default).
7.) Dialog "Edit receiving address": Address shouldn't be a text field if you can't actually change it? Not sure about that though.
8.) Dialog Address Book, Tab Sending:
   a.) "Copy to Clipboard", "Edit" and "Delete" should be greyed out, if no address is selected.
   b.) If you add a new entry without giving the address (just the label) it says: "The address is already in the address book.". I think it should not even allow an entry without a valid address.
9.) Send Coins dialog:
   a.) Having a separate entry field for the [insert missing word] and [again] is a very good idea. It might save some trouble. I also noticed, that pressing "." or "," will send you to the second box. Excellent!
   b.) I'd like to suggest a different behavior for the "Add to address book"-shortcut. Remove the checkbox and the text "Add to address book". Simply add the text "Label:" right below "Pay To". The text-field for the address book entry stays disabled until the user inputs (or pastes, or chooses from address book) some address above. Now, if the address is found in the address book, just display the label from the address book. The user has the option to not touch it, or to correct the label which is automatically saved when pressing Send. If it wasn't found it shows a placeholder text with something like "Optional: Enter a label for this address to add it to your address book." If the user enters something it gets in the address book, if not not.
10.) You are giving instructions in your readme how to compile it in ubuntu. On a fresh install of Ubuntu 10.04 I needed the following not mentioned packages to get it building: build-essential, libboost-dev, [libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev | libboost-all-dev], libssl-dev and libdb4.8++-dev. Actually it didn't build, because setPlaceholderText in QLineEdit was introduced in Qt4.7 and Ubuntu 10.04 comes with Qt4.6. I commented them out.

Well, that was more to write than I expected. If you made it that far, I'd like to thank you for your attention. 
If anything is unclear, please ask. I know I understand my own "english", others might not?

[1] But please translate it to proper english first 

Yes, I intend to do something like this. The client would have tabs "overview" (open by default) "transaction history" (as it is now), "address book" and "receiving addresses".
Yep that would be nice. This would require a change to the core client code though, as it does not currently keep track of the total number of blocks as received from other nodes:

https://forum.bitcoin.org/index.php?topic=17485.0

Two suggestions:

First, how about making the transaction history collapsible, and hidden by default, showing just a dashboard thingy when collapsed; the dashboard would should how much money was sent, how much money received and the current balance, with optionally also displaying the the unconfirmed amounts for each one of those as well as the what each value would be if you add up the unconfirmed transfers to the confirmed (perhaps even allowing people to specify which of those they wanna show, and perhaps even a compact mode showing just the currently avaiable total (with the count of unconfirmed transactions shown in the statusbar or somthing, and when clicked it gets expanded to show the unconfirmed transfers)



And regarding the block count display, how about showing somthing like 123456/234567 (and 123456/? when the current total count is unknown) ?

Ok good idea. The editing could even happen inline in the table, so that separate edit boxes are not needed.
Combined with a ghost row that would allow removing two of the buttons.

The list is not sorted by creation date but by label or address. So the ghost row could be anywhere. On top would make the most sense IMO, as the top row is visible when the window opens.

I've changed the order to "Label (address...)". Indeed looks better. As you can have multiple addresses with the same label, completely removing the address is not possible.

Also some people have suggested that they want to see the addresses in any case; to see whether they have the right one.

It was originally not meant as a fork of the mainline bitcoin. In the beginning I wasn't sure whether to link it directly or go through RPC. I'm not sure whether it is still possible to make it a fork.

Is there a reason why this project isn't done as a fork of bitcoin on github?  It seems to me that it would be easier to integrate changes from the core of the reference client if it was.

(By the way, that's intended as a respectful question and not a criticism just in case it comes across that way.)

In the main window there are after the addresses the addressbook's aliases in paretheses. How about only writing the aliases and displaying the related addresses on small pop up tip tool, when the mouse hovers over the alias? Or at least exchange the order of the information to "alias (address)"?

Or edit could be beside the highlighted row and new address be beside the ghost row, which in the image provided seems to be the bottom rather than the top. (It should be wherever the newest would be, so top or bottom depending on whether displaying oldest or newest at top).

Copy to clipboard tends in any case to familiarly be related to something that is highlighted, at least in Windows and Linux, I don't know how Mac does it. So maybe that need not move, often I have seen Windows users go to some menu in upper left of their screen to find a copy/cut/paste menu so surely they are used to it not having to be right next to the highlighted thing it is to apply to.

-MarkM-

I'd suggest having two edit boxes that reflect the contents of the currently selected row. Changing the contents of the edit box changes the table.

To add a new row, there could be a "ghost row" at the top. Clicking on it makes the edit boxes empty. Setting them to something creates a new row. Note that this would allow invalid rows (eg empty address), but that's OK, they can just be ignored in the rest of the code.

Thanks, I'll take a look at that. As Qt Creator supports it it'd probably be the best bet. I really hate fooling around with m4 scripts as with autoconf, the only reason I mentioned that is because the mainline client wants to switch to it.  Maybe we should do a post to the mailing list promoting cmake instead of automake?

...

I'm not so happy with the current address book window;



Especially the action buttons at the bottom of the window seem to be unintuitive to me; usually, buttons at the bottom apply to the entire dialog box, not items in a list.

Can someone more versed on sane UI design comment on this? Would it make more sense to put the buttons elsewhere?

Hmmm, I have no idea, why sometimes Knotify accepts longer messages. Here are some examples of receiving notify:
http://img708.imageshack.us/img708/6855/bitcoinqt4.png
http://img59.imageshack.us/img59/6594/bitcoinqt5.png

What about qconf? Project from Psi developers.

If you're interested in good example of using CMake with bitcoin sources you can look at sources of rpcminer. It have fork of Bitcoin with CMake.

The problem with qmake is that it is not intelligent enough to handle changes in library names (common with boost) and doesn't offer installation.

cmake, on the other hand, yes that might be a good choice because it can also generate native Visual C++ / XCode build files.

I'm not a that much of a fan of autotools either.

You can link from mingw to C libraries compiled with Visual C. C++ doesn't work because it uses a different ABI. Or at least that used to be the case.

Mingw is generating libraries for Windows, so you can use without problem from VS in mingw or from mingw in VS.

I've only tried mingw so far as it's integrated with QT Creator.  As I understand it there can be big problems trying to link libraries compiled by MS VS to a program being compiled in mingw (I'm not an expert on Windows type stuff, but nobody else seemed to be actively trying...)