This pull request adds a debug window to the UI (can be opened through Help → Debug window). This includes:
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:
18 | + ~RPCConsole(); 19 | + 20 | + void setClientModel(ClientModel *model); 21 | + 22 | + enum MessageClass { 23 | + ERROR,
This (and probably the next one) are #defined somewhere on Windows, breaking the build. Perhaps call it MC_ERROR, if there's really a need for 2 different ERROR values (this and CMD_ERROR). eg, a0031e5
Right... Is there a list of the namespace-polluting crap macros that windows dumps into programs somewhere?
And yes, ERROR and REQ_ERROR are different, the first category is meant for general critical errors the other is simply a failed RPC command.
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.
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)
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"
Milestone
0.7.0