search

slimcoin-project / pacli

Simple CLI PeerAssets client (extended version).
GNU General Public License v3.0
0 stars 0 forks source link

Nice to have enhancements #167

Open buhtignew opened 4 months ago

buhtignew commented 4 months ago

Instead of creating a thread for each small command's improvements that pops up while using them I've thought we can have a general thread like that of the Typos just putting everything which may seem to be useful here. If you think that this thread is not helpful it this stage let's just close it. _ I'm not 100% sure whether we've already discussed this or not but what if we suppress the -a flag in the address set command so as the user could just put the label or the address indifferently in the first position? Otherwise the user needs to know the label of the address, which sometimes can require a bit of additional research or he should remember that the -a flag before the address is needed. That's of course not a big deal, but maybe it would improve a little bit the usability.

d5000 commented 3 months ago

I'm still not working on this but adding the following suggestion from the help thread, which is not help-related:

IDK whether it would make sense for the average user, but during my testing I've realized that it would be useful to have the address list displaying the block on which the data is displayed.

I'm considering it.

buhtignew commented 3 months ago

I think it would be nice to have a command or a flag that would enable to search a deck by parameters. For instance if I launch token show ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -i I can see the complete info about the deck ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58, but what if I'd like to find a deck that has that at_address or that startblock (one of parameters included in the above command's output) without knowing the deck's id in advance? _

As mentioned here I think it would be suitable to add a compatibility check into the pobtoken claim command in order to prevent people spending their fees on claiming tokens for the decks with the startblock that occurs after the burning transaction was created.
The same for the attoken claim command.
_

As mentioned here I think it would be nice to have not only the courtesy message for the PoD tokens used accidentally with transaction list DECK -b usage mode (for instance transaction list DTNewSpecv2 -b) but also for the ATtokens (or any other token that is not PoB) used by chance with the same usage mode (for instance transaction list ATTokenNotPoB -b). If we opt for this solution the message for all the cases other than with the PoB token (i.e. transaction list PoD_token -b, transaction list ATToken -b, transaction list ANY_NOT_POB_TOKEN -b) should be changed from Deck xxxxxxxx is not an AT or PoB token deck. into Deck xxxxxxxx is not a PoB token deck.

d5000 commented 1 month ago

I think currently it's good as it is and thus I'm closing:

Both are different checks, thus it makes sense that the messages are different, and the first error can potentially also be thrown in other situations, thus the "probably".

buhtignew commented 1 month ago

I think your reply above refers to #209, which I'm closing, but this thread has other matters we are keeping there just in case we'll decide to implement them in the future. I'm reopening.

buhtignew commented 1 week ago

There are two above comments of us that are not appropriate for this issue. The post above them is still pending. However I'll be adding things in this post new post if any. _ I feel it would be useful to have a flag or a combination of flags for address list that would allow people to see all the addresses in their wallet both P2TH and not P2TH (a kind of complete list made of address list -i and address list -p outputs).