I would find it more convenient, if the debug window could be shown as main tab. Changing the option needs client restart.


I would find it more convenient, if the debug window could be shown as main tab. Changing the option needs client restart.


Hmm... I like the idea of being able to call the debug window from the main screen, but I'm not sure this is the right way. I think some restructuring would be needed to accomedate this.
The tab pages are 'wallet tabs', internally part of the wallet view. The debug window is not supposed to have anything to do with a particular wallet(view) but with the P2P client itself. Apart from being inconsistent this would give problems in case multiple wallets could be loaded, for example (there would be multiple walletviews, each containing the debug window?)
Also in no-wallet mode the tabs don't appear at all. This complicates the code between 'debug window as window', 'debug window as wallet tab', and 'debug window as main widget'.
The Debug window could be a 'wallet' at the level of WalletFrame not WalletView. This reduces the amount of cases to two again: 'debug window as walletframe child' and 'debug window as window' in the case of no-wallet mode the debug window would be the only 'wallet'.
ie
BitcoinGUI
WalletFrame (could be renamed to something else if it can contain other children as well...)
WalletView [Wallet 1]
WalletView [Wallet 2...]
RPCConsole [Debug window]
update:
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/a7d0d70207cec729a06854422d709faac8e4b385 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
It makes zero sense to have the debug window (which should only ever be used by power users, since it exposes dangerous commands that affect wallet internals) promoted to a tab, yet forcefully stop people from choosing to have the sign/receive (which is common use for any kind of user) available as a tab...
What is the reasoning behind stopping those other windows from being used as tabs?
I still like the idea, but agreed with @luke-jr that this should probably be solved in a more general way, letting people configure windows/tabs as they like. I think being able to right-click the toolbar, which opens a checkbox list would be great. Bonus if you could reorder the tabs. So closing for now, until someone has a better idea.
I'm not married to the idea of tabs.
Keeping the number of tabs down was a motivation in the past to not make the software appear too daunting.
But we'll have to redesign the interface a bit if we want to support multiple wallets, which makes the navigation more like a kind of two-level structure:
- Wallet 1
- Overview
- Send
- Receive
- possibly Sign message
- possibly Verify message
- Wallet 2
....
- Debug
....
The current use of tabs becomes really strange in that case (how the signals are connected and the tab signals need to pass down the WalletView hierarchy is already telling).
Also in general I'm against having a lot of options/configurability as this makes testing exponentially more work intensive, so it would be nice if we could come up with something that simply works.