Wow, nice!

Small request: make responses copy-pastable.

They are (though not really intuitively), you can click on the table cell
and press ctrl-c

I really like the idea, but would place the function under help and add a seperator line. It simply is no setting or option :). Is there a way export to a text file? Would be consistent to offer such a function, as this is possible "all over the GUI".

It's not help either, nor file. We really need a "tools" menu like other
programs. Maybe the settings menu could be renamed "tools", then it makes
more sense.

Exporting the console contents to a file could be useful. I'll keep that in
mind for a future update.

Sign message would be a tool, too then ;). So why not create a new tools point, which holds your console and the sign message dialog?

Rebased, added build date to info window

New commit moved the option to the "Help" menu (until we have something better) and adds explicit "Copy" context menu to console.

Nifty. Tagged for 0.7.

Rebased, I've been able to structure the code better because of the recent RPC refactorings:

• Added a execute() method to CRPCTable.
• Factored out function RPCConvertValues() to convert parameter values for RPC call from list of strings to command-specific JSON objects.
• LocalRPC is completely gone (and with it, most changes to the core), no more code additions to bitcoinrpc.cpp. This is now integrated into the Qt code, making use of CRPCTable::execute.

Pretty awesome. Should this go under a tools menu or should it really be burried under help->debug window->console tab?

Does everyone else really like the nested scrollbars you get? (type help a couple times) I'm concerned that this might confuse users that I'm trying to support "scroll down and you'll see it" "I'm scrolled all the way down!". It's also a bit annoying if you're running a command over and over again to see if something changes to have to scroll internally to the entry to see it. (e.g. run getinfo over and over looking for connections changing)

Also, the fact that you can't copy large chunks of commands is bad from a support perspective. Its helpful if people can say "I ran all these commands and got all these results".

Sending the stop RPC makes the UI lockup for a long time (30 seconds?) before eventually shutting down.

When I first bring up the console focus doesn't move to the text entry box. I have to click it. But it has a blinking cursor even before I do, I think the focus is on the output box.. so it doesn't seem responsive. This only happens the first time after startup. After that it seems to remember.

The green and grey boxes don't seem all that intuitive to me. I'd personally just put [request] [reply]. But I admit this this is mostly taste and you should probably ignore me.

Copy works differently in single element responses vs multi-element responses. E.g. type "getblockhash 5" copy the hash, then "getblock [paste]" and copy the first txn hash. If you do something that has the second behavior first you may believe that it's not possible to copy in the first case, because you don't get any incremental selection. I think ideally incremental selection should always work.

• Eventually it makes sense to add a tools menu where Sign message and verify message should also go. However, it's hidden in the second tab for a good reason. Users should not stumble too easy on it so it's now a second tab of a dangerous-looking window.
• I don't like the nested scrollbars either. However, the Qt QTableWidget doesn't like rows that are too tall (they break scrolling, as the y offset can only start at a whole cell). That's why tall cells get them.
• Selecting and copying multiple cells could be added.
• Yes it should probably focus the input box when the tab is selected.
• Typing the "stop" RPC command hangs the UI for as long as it takes to shutdown: seems that the UI is not hidden in this case when it leaves the main loop (could be easily fixed, this problem is not related to the console but happens also when you shut down some other way). (fixed by Hide UI immediately after leaving the main loop #1209)
• The green and grey boxes are categories, they should go together with filtering. I intend to add buttons at the top with the same boxes to hide/show them (I also want to add normal debug/error messages). I'm open to suggestions as to the colors, or even icons (boxes are placeholders), but I don't want to much discussion about this.

IMO given that there are no critical issues we should merge this as soon as possible. It's better to have something, and it is functionality only a very small part of people will use, so perfecting it is not the foremost priority.

ha. I didn't mean to imply it shouldn't be pulled because of any of that. I just sat down and ran through it and what I wrote is just a braindump what I found. Considering that its a GUI feature, the fact that I actually tried to break it shows how excited I am to get it in. :)

However, it shouldn't be pulled this second because we may cut a 0.6.2 to take the addrman crash fix.

I agree, thanks for testing!

Object::connect: No such signal ClientModel::numBlocksChanged(int) in src/qt/rpcconsole.cpp:161
Object::connect: (receiver name: 'RPCConsole')

(this is with next-test, so maybe an undetected merge conflict)

Yes, that's an undetected merge conflict. numBlocksChanged changed from one to two arguments in #1205.

DO WANT!

On a side note, does it show all debug messages, or just RPC requests?

Oh, gruez has a nice point. This needs a debug log viewer tab too. :) Getting random windows users to find the debug log is an amazing PITA.

Windows users are ticking a little different, don't blame them ^^. But ACK to the debug viewer idea, perhaps in a seperate commit, to not bloat this one?

I don't blame them— I'm very happy they use Bitcoin. But finding files in the file system and viewing them with wordpad isn't something most windows apps ask people to do, so they don't know how to do it. And because I know nothing about windows its very hard for me to talk them through it. A log viewer in bitcoin is something I could bring up locally. :) And sure, if I'm not doing the work I'm in no position to ask about which commits it gets placed in. ;)

I'm not going to add a full log viewer. There's zillions of those. That problem has been solved by grumpy system admins way before my time. Better to just implement logging to the OS log, if you want that, so you can use your operating system's log viewer.

However, it was my intention to show the last N debug and error messages for debugging, eventually (not necessarily in this commit).

Maybe we're thinking too difficult: on windows, we could just add a button to the debug window that opens debug.log in a wordpad?

::facepalm:: "The Russians Used a Pencil"