This means that users can verify an explorer is correct and matches their node, and look at very old block height info that our explorers currently do not render.
Users should be able to look up something like the block page of an explorer https://explorer.hush.is/block/1133177/ directly in their SD GUI.
This means that users can verify an explorer is correct and matches their node, and look at very old block height info that our explorers currently do not render.
What should the GUI of this look like? Perhaps it's an "application" (there is only validate address there now) where you put in a block height and then a modal popup is shown with the details. Also a user could right click on a tx and there could be an option "view details about block containing this tx"
What should the GUI of this look like? Perhaps it's an "application" (there is only validate address there now) where you put in a block height and then a modal popup is shown with the details. Also a user could right click on a tx and there could be an option "view details about block containing this tx"
I have an initial commit for this in dev branch. It's under apps with validate address for now. Uses the same model and might make sense to rename or create separate model.
Code also needs to be modified to handle numeric values correctly. Currently only display a string or true/false for anything that's not a string.
I have an initial commit for this in `dev` branch. It's under apps with validate address for now. Uses the same model and might make sense to rename or create separate model.
Code also needs to be modified to handle numeric values correctly. Currently only display a string or true/false for anything that's not a string.
@fekt I really like this and think it's very important for reducing metadata leakage of users. Instead of going to an explorer and leaking all kinds of metadata, users can verify details via their own node.
@fekt I really like this and think it's very important for reducing metadata leakage of users. Instead of going to an explorer and leaking all kinds of metadata, users can verify details via their own node.
@fekt looks like you forgot to add src/getblock.ui :
WARNING: Failure to find: src/getblock.ui
Makefile:1886: warning: overriding recipe for target 'src/ui_viewalladdresses.h'
Makefile:1878: warning: ignoring old recipe for target 'src/ui_viewalladdresses.h'
Makefile:1898: warning: overriding recipe for target 'src/ui_viewalladdresses.h'
Makefile:1886: warning: ignoring old recipe for target 'src/ui_viewalladdresses.h'
make: *** No rule to make target 'src/getblock.ui', needed by 'src/ui_getblock.h'. Stop.
@fekt looks like you forgot to add `src/getblock.ui` :
```
WARNING: Failure to find: src/getblock.ui
Makefile:1886: warning: overriding recipe for target 'src/ui_viewalladdresses.h'
Makefile:1878: warning: ignoring old recipe for target 'src/ui_viewalladdresses.h'
Makefile:1898: warning: overriding recipe for target 'src/ui_viewalladdresses.h'
Makefile:1886: warning: ignoring old recipe for target 'src/ui_viewalladdresses.h'
make: *** No rule to make target 'src/getblock.ui', needed by 'src/ui_getblock.h'. Stop.
```
@fekt ok, I can confirm basic functionality. In addition to rendering integer values correctly, it would be nice to see some other values, such as the number of transactions in the block and the address of the block miner.
One weird thing I noticed, which may be inherited from the code that "Validate Address" uses is that on a slow wallet, when the transactions tab is still waiting for RPC data, if you do "View Block" nothing appears to happen. It lets you submit multiple "View Block" requests, and then when the transaction tab is done loading, all the "View Block" modals will popup up at once. This also seems to happen when not loading the transactions tab, it takes multiple minutes or more for "View Block" modal to popup.
Another weirdness is that the View Block modal can be resized but if you attempt to drag it around, the entire SD window moves with it (on Linux).
@fekt ok, I can confirm basic functionality. In addition to rendering integer values correctly, it would be nice to see some other values, such as the number of transactions in the block and the address of the block miner.
One weird thing I noticed, which may be inherited from the code that "Validate Address" uses is that on a slow wallet, when the transactions tab is still waiting for RPC data, if you do "View Block" nothing appears to happen. It lets you submit multiple "View Block" requests, and then when the transaction tab is done loading, all the "View Block" modals will popup up at once. This also seems to happen when not loading the transactions tab, it takes multiple minutes or more for "View Block" modal to popup.
Another weirdness is that the View Block modal can be resized but if you attempt to drag it around, the entire SD window moves with it (on Linux).
Sounds funky. The requests seemed to load quick on my end but the wallet I was using is pretty fresh. Might be some other background RPC calls blocking requests.
I really only added the RPC call and used the same stuff from "Validate Address". I've seen that dragging window issue on Linux with other modals like the memo, but it doesn't seem to happen on Windows. Might be a QT thing. Will take a look when I can.
Sounds funky. The requests seemed to load quick on my end but the wallet I was using is pretty fresh. Might be some other background RPC calls blocking requests.
I really only added the RPC call and used the same stuff from "Validate Address". I've seen that dragging window issue on Linux with other modals like the memo, but it doesn't seem to happen on Windows. Might be a QT thing. Will take a look when I can.
One other funky thing I noticed is that it's possible to input garbage data for the block height. We should only allow block height to be an integer value.
One other funky thing I noticed is that it's possible to input garbage data for the block height. We should only allow block height to be an integer value.
I changed the dialog to use getInt. I couldn't reproduce resizing the modal and then it dragging entire window around on Debian Bullseye. Only the modal moved, but I've definitely seen it before with other modals. Maybe on Ubuntu (didn't test there yet). I tried with the main app Window minimized and maximized and not sure how to reproduce.
I changed the dialog to use getInt. I couldn't reproduce resizing the modal and then it dragging entire window around on Debian Bullseye. Only the modal moved, but I've definitely seen it before with other modals. Maybe on Ubuntu (didn't test there yet). I tried with the main app Window minimized and maximized and not sure how to reproduce.
@fekt sweet, I will test the new code soon. I am not too worried about the GUI modal dragging bug, I just wanted to document it. It's probably specific to OS and QT version.
Other things to think about are the tx and valuePools fields. tx is an array which often just has one or a few elements but it could have potentially hundreds, so I am not sure the best way to render it. If we do render txids, I think it would be really nice to be able to right click on them and have an option to either copy them to the clipboard or view them on an explorer.
For valuePools we can ignore the "sprout" keys (I am just going to remove them from hushd, it's useless data that will always be zero) and then we can render the current size of the sapling pool there, if we want.
@fekt sweet, I will test the new code soon. I am not too worried about the GUI modal dragging bug, I just wanted to document it. It's probably specific to OS and QT version.
Other things to think about are the `tx` and `valuePools` fields. `tx` is an array which often just has one or a few elements but it could have potentially hundreds, so I am not sure the best way to render it. If we do render txids, I think it would be really nice to be able to right click on them and have an option to either copy them to the clipboard or view them on an explorer.
For `valuePools` we can ignore the "sprout" keys (I am just going to remove them from hushd, it's useless data that will always be zero) and then we can render the current size of the sapling pool there, if we want.
Users should be able to look up something like the block page of an explorer https://explorer.hush.is/block/1133177/ directly in their SD GUI.
This means that users can verify an explorer is correct and matches their node, and look at very old block height info that our explorers currently do not render.
What should the GUI of this look like? Perhaps it's an "application" (there is only validate address there now) where you put in a block height and then a modal popup is shown with the details. Also a user could right click on a tx and there could be an option "view details about block containing this tx"
I have an initial commit for this in
devbranch. It's under apps with validate address for now. Uses the same model and might make sense to rename or create separate model.Code also needs to be modified to handle numeric values correctly. Currently only display a string or true/false for anything that's not a string.
@fekt I really like this and think it's very important for reducing metadata leakage of users. Instead of going to an explorer and leaking all kinds of metadata, users can verify details via their own node.
I also think it would be very useful to be able to right click on a transaction and there be an option "View block containing this transaction"
@fekt looks like you forgot to add
src/getblock.ui:I'll check in a few and commit it.
Should be there now. Code still needs tweaks for some of the values.
@fekt ok, I can confirm basic functionality. In addition to rendering integer values correctly, it would be nice to see some other values, such as the number of transactions in the block and the address of the block miner.
One weird thing I noticed, which may be inherited from the code that "Validate Address" uses is that on a slow wallet, when the transactions tab is still waiting for RPC data, if you do "View Block" nothing appears to happen. It lets you submit multiple "View Block" requests, and then when the transaction tab is done loading, all the "View Block" modals will popup up at once. This also seems to happen when not loading the transactions tab, it takes multiple minutes or more for "View Block" modal to popup.
Another weirdness is that the View Block modal can be resized but if you attempt to drag it around, the entire SD window moves with it (on Linux).
Sounds funky. The requests seemed to load quick on my end but the wallet I was using is pretty fresh. Might be some other background RPC calls blocking requests.
I really only added the RPC call and used the same stuff from "Validate Address". I've seen that dragging window issue on Linux with other modals like the memo, but it doesn't seem to happen on Windows. Might be a QT thing. Will take a look when I can.
One other funky thing I noticed is that it's possible to input garbage data for the block height. We should only allow block height to be an integer value.
I fixed the code to render integer values correctly
I changed the dialog to use getInt. I couldn't reproduce resizing the modal and then it dragging entire window around on Debian Bullseye. Only the modal moved, but I've definitely seen it before with other modals. Maybe on Ubuntu (didn't test there yet). I tried with the main app Window minimized and maximized and not sure how to reproduce.
@fekt sweet, I will test the new code soon. I am not too worried about the GUI modal dragging bug, I just wanted to document it. It's probably specific to OS and QT version.
Other things to think about are the
txandvaluePoolsfields.txis an array which often just has one or a few elements but it could have potentially hundreds, so I am not sure the best way to render it. If we do render txids, I think it would be really nice to be able to right click on them and have an option to either copy them to the clipboard or view them on an explorer.For
valuePoolswe can ignore the "sprout" keys (I am just going to remove them from hushd, it's useless data that will always be zero) and then we can render the current size of the sapling pool there, if we want.sprout key has been removed from
valuePoolsin dev branchcalling this done, although there are some bugs and improvements needed. Will make issues directly for those