Added transaction categories for beacon and voting #973

Pythonix · 2018-02-27T15:43:40Z

I have added two new transaction categories. One for voting and one for sending the beacon.
The category for sending the Beacon does not yet have its own icon.

This would close #389

iFoggz · 2018-02-27T17:51:18Z

We use 4 spaces not tabs
no spaces after a {
ex:

if (currentcondition == statecondition)
{
1234command structure here
}

if (a == b)
{
1234command structure here
}

void dummyfunction()
{
1234command structure here.
}

Like the idea so please clean it up cheers

1234 is the spacing since i havent had my coffee yet and forgot the code block

iFoggz · 2018-02-27T22:45:37Z

src/qt/transactionrecord.cpp

@@ -163,8 +164,31 @@ QList<TransactionRecord> TransactionRecord::decomposeTransaction(const CWallet *
                if (ExtractDestination(txout.scriptPubKey, address))
                {
                    // Sent to Bitcoin Address
-                    sub.type = TransactionRecord::SendToAddress;
-                    sub.address = CBitcoinAddress(address).ToString();


// Sent to testnet or mainnet vote / beacon address if (sub.address == GetBurnAddress()) { std::vector<std::pair<std::string, std::string>> vTxNormalInfoIn = GetTxNormalBoincHashInfo(wtx); for (const auto& vTxNormalInfo : vTxNormalInfoIn) { if (vTxNormalInfo.first == "Message Type") { if (vTxNormalInfo.second == "Vote" || vTxNormalInfo.second == "Add Poll") { if (fDebug) OutputDebugStringF("Vote/Add Poll\n"); sub.type = TransactionRecord::Vote; break; } else if (vTxNormalInfo.second == "Add Beacon Contract") { sub.type = TransactionRecord::Beacon; break; } /* Message icon example as well else if (vTxNormalInfo.second == "Text Message") { sub.type TransactionRecord::Message; break; } */ // Message type is not one we are checking for. end the for auto loop else break; } } } }

that is likely better @denravonska may chime in that

the Message icon part is if u add a message icon change as i asked

iFoggz · 2018-02-27T22:46:13Z

src/qt/transactionrecord.cpp

@@ -2,13 +2,14 @@
 #include "wallet.h"
 #include "base58.h"

+std::vector<std::pair<std::string, std::string>> GetTxNormalBoincHashInfo(const CMerkleTx& mtx);
 std::string GetTxProject(uint256 hash, int& out_blocknumber, int& out_blocktype, double& out_rac);



if u use the suggested code block below add here
std::string GetBurnAddress();

tomasbrod · 2018-02-27T23:10:27Z

I do not remember you @Pythonix. Please do not take the white-space criticism personally. It is a minor thing. Either fix it or say you won't.
I am saying that, because I was new too and got pissed of by white-space complaints.

Pythonix · 2018-02-27T23:12:14Z

I don't take it personally. I'm glade for the help @Foggyx420 offered me and I'm happy to change my code.

iFoggz · 2018-02-28T03:03:30Z

I wasn't criticizing at all. N I did help him get it going.

denravonska · 2018-02-28T07:45:10Z

@Pythonix @tomasbrod Don't just say you won't do it unless you can argue why, other than lazyness. I have a 3-year old who does that and it's super annoying.

added categories for send/receive message and send/receive rain

iFoggz · 2018-02-28T17:07:27Z

@denravonska travis fails to find the icon file idk if it has not pulled it from the pr or its just a travis issue. I successfully compiled his branch for that icon locally linux 64

TheCharlatan · 2018-03-04T11:08:38Z

The .svg file needs to be added to the RES_ICONS file list in Makefile.qt.include. This should fix the travis issue.

TheCharlatan · 2018-03-05T00:38:53Z

There is still one error: The SendMessage enum seems to conflict with a macro when compiling with mingw32. Either add

#undef SENDMESSAGE
#undef SendMessage

To transactionrecord.h and .cpp and transactiontablemodel.cpp , or rename the SendMessage enum to something that does not conflict.

tomasbrod

I will have a look how this could be improved.

tomasbrod · 2018-03-05T22:33:36Z

src/qt/transactionview.cpp

+    typeWidget->addItem(tr("Vote"), TransactionFilterProxy::TYPE(TransactionRecord::Vote));
+    typeWidget->addItem(tr("Beacon"), TransactionFilterProxy::TYPE(TransactionRecord::Beacon));
+    typeWidget->addItem(tr("Sent message"), TransactionFilterProxy::TYPE(TransactionRecord::SendMessage));
+    typeWidget->addItem(tr("Received message"), TransactionFilterProxy::TYPE(TransactionRecord::RecvMessage));


What if the transaction is "To yourself" "Sent message" and "Received message" at the same time?

tomasbrod · 2018-03-05T22:36:31Z

src/qt/transactionrecord.cpp

+                    std::vector<std::pair<std::string, std::string>> vTxNormalInfoIn = GetTxNormalBoincHashInfo(wtx);
+                    for (const auto& vTxNormalInfo : vTxNormalInfoIn)
+                    {
+                        if (vTxNormalInfo.first == "Message Type")


This will probably fail when localized.

tomasbrod · 2018-03-05T22:38:09Z

src/qt/transactionrecord.h

+        SendToSelf,
+        Vote,
+        Beacon,
+        SendMessage,


Macros are evil in c++. I suggest the #undef option.

iFoggz · 2019-08-21T06:30:09Z

Anything left to be done with this?

jamescowens

I think Tomas is right. The vTxNormalInfo stuff... "Message Type" is not safe under localization. We need to rethink this...

jamescowens · 2019-08-24T20:51:39Z

@iFoggz There are a lot of changes that were made to transactionrecord.cpp for sidestaking that are going to make the merge resolution very tricky.

iFoggz · 2019-08-24T22:33:50Z

Localization as in language of the client user?

The data stored in the blocks for messages, etc is unaffected by the translations as those are done at compile for what we have slated to have available translations.

Example the boincHash stuff always in english.
If a chinese user sends a chinese message to a user they receive the message in chinese however the boincHash is still the way it is coded.
vTxNormalInfo is always in same format regardless of localization. if it wasn't we would have to compensate for every localization

I cannot tie anything here that suggests translation macros would affect our core code or block boincHash format.

If anyone has any ideas of this please let me know.

as for merge conflicts since other areas have been done it will be better to redo this ontop of current code base to make this more clean and more fitting into existing changes.

jamescowens · 2019-08-24T22:37:59Z

I concur with all your comments.

…

Sent from my iPhone

On Aug 24, 2019, at 6:33 PM, Paul Jensen ***@***.***> wrote: Localization as in language of the client user? The data stored in the blocks for messages, etc is unaffected by the translations as those are done at compile for what we have slated to have available translations. Example the boincHash stuff always in english. If a chinese user sends a chinese message to a user they receive the message in chinese however the boincHash is still the way it is coded. vTxNormalInfo is always in same format regardless of localization. if it wasn't we would have to compensate for every localization I cannot tie anything here that suggests translation macros would affect our core code or block boincHash format. If anyone has any ideas of this please let me know. as for merge conflicts since other areas have been done it will be better to redo this ontop of current code base to make this more clean and more fitting into existing changes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

jamescowens · 2019-08-25T14:33:19Z

So we have confirmed that localization is not an issue here. We have a lot of conflicts in transactionrecord.cpp because this was extensively modified for sidestaking. Given that, ifoggz is going to redo this on top of the head of development and put up another PR to control the regression risk. I concur with that strategy. We will leave this open until the new PR is up.

cyrossignol · 2019-08-25T19:25:27Z

This implementation uses GetTxNormalBoincHashInfo() which applies localization to the identifiers that these changes rely on for categorizing the transactions:

Gridcoin-Research/src/rpcrawtransaction.cpp

Line 116 in ddaaf8d

res.push_back(std::make_pair(_("Message Type"), _("Add Beacon Contract")));

As it is written here, we'll get the desired behavior de facto because none of the translation units contain a valid substitution for those identifiers yet. If someone adds localization for those in a language besides English, the categorization will break when the wallet is configured to use that language:

Gridcoin-Research/src/qt/transactionrecord.cpp

Line 80 in fa78bf1

if (vTxNormalInfo.first == "Message Type")

To avoid the localization issue, we need to remove the localization from GetTxNormalBoincHashInfo() or write a new routine that tags the transactions with real constants.

jamescowens · 2019-08-25T20:05:15Z

The issue with doing your second option is that it is not backwards facing, whereas playing games with the messages is a UI model only thing that is entirely local on the node. Bad set of choices IMHO.

cyrossignol · 2019-08-25T20:16:14Z

@jamescowens Sorry for being unclear--I'm not suggesting any changes to the protocol. The second solution that I proposed should just do what the wallet already does here but in a way that doesn't rely on localized strings. The GetTxNormalBoincHashInfo() function just parses a transaction into a presentation structure for output. The changes in this PR just need a similar structure that's not dependent on localization (so we're still only playing games in the UI code 🙂 ).

jamescowens · 2019-08-25T20:41:26Z

@iFoggz ^ See @cyrossignol's comments.

iFoggz · 2019-09-17T22:16:36Z

this should be redone on latest commits.and GetTxNormalBoincHashInfo just reads whats in the transaction if does not have anything to do with language localization but i will look to redo most this and from there. i have not reviewed most of this code.

Pythonix added 2 commits February 27, 2018 16:24

added a special category for beacon / vote transactions

7932204

make it work with debug=true

a45171b

changed tabs to spaces and added GetBurnAddress()

f5bbcc6

iFoggz reviewed Feb 27, 2018

View reviewed changes

changed code as Foggyx420 suggested

37a9481

added categories for send/receive message and send/receive rain

Pythonix added 2 commits March 4, 2018 18:35

added tx_vote.svg to Makefile.qt.include

23426ad

removed debug comment

eb788e5

tomasbrod reviewed Mar 5, 2018

View reviewed changes

tomasbrod mentioned this pull request Apr 27, 2018

Added transaction categories for beacon and voting #1067

Closed

denravonska modified the milestones: Camilla the Chicken, Betsy Bird Jun 19, 2018

Add workaround for Windows defining SendMessage to SendMessageW.

143db58

denravonska modified the milestones: Betsy, Camilla Aug 1, 2018

tomasbrod mentioned this pull request Aug 21, 2018

Remove 0123 0124 detection to determine POS/POR #1270

Closed

jamescowens mentioned this pull request Aug 22, 2018

Side staking (extends stake splitting PR #1244) #1265

Merged

iFoggz mentioned this pull request Sep 10, 2018

Removal of 0123 0124 & implementation of GenerateType/MinedType #1295

Closed

try a fix for travis

fa78bf1

jamescowens modified the milestones: Camilla, Denise Mar 7, 2019

jamescowens modified the milestones: Denise, Elizabeth Mar 30, 2019

jamescowens modified the milestones: Elizabeth, Fern Aug 8, 2019

jamescowens requested changes Aug 24, 2019

View reviewed changes

jamescowens mentioned this pull request Oct 5, 2019

task: Transaction Model redo #619

Closed

jamescowens modified the milestones: Fern, Gladys Feb 23, 2020

jamescowens mentioned this pull request Jun 6, 2020

Implement beacon, vote, and superblock display categories/icons in UI transaction model #1717

Merged

jamescowens closed this Jun 6, 2020

jamescowens removed this from the Gladys milestone Aug 19, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added transaction categories for beacon and voting #973

Added transaction categories for beacon and voting #973

Pythonix commented Feb 27, 2018

iFoggz commented Feb 27, 2018 •

edited

Loading

iFoggz Feb 27, 2018

iFoggz Feb 27, 2018

iFoggz Feb 27, 2018

tomasbrod commented Feb 27, 2018 •

edited

Loading

Pythonix commented Feb 27, 2018

iFoggz commented Feb 28, 2018

denravonska commented Feb 28, 2018 •

edited

Loading

iFoggz commented Feb 28, 2018

TheCharlatan commented Mar 4, 2018

TheCharlatan commented Mar 5, 2018

tomasbrod left a comment

tomasbrod Mar 5, 2018

tomasbrod Mar 5, 2018

tomasbrod Mar 5, 2018

iFoggz commented Aug 21, 2019

jamescowens left a comment

jamescowens commented Aug 24, 2019

iFoggz commented Aug 24, 2019

jamescowens commented Aug 24, 2019 via email

jamescowens commented Aug 25, 2019

cyrossignol commented Aug 25, 2019

jamescowens commented Aug 25, 2019

cyrossignol commented Aug 25, 2019

jamescowens commented Aug 25, 2019

iFoggz commented Sep 17, 2019

Added transaction categories for beacon and voting #973

Added transaction categories for beacon and voting #973

Conversation

Pythonix commented Feb 27, 2018

iFoggz commented Feb 27, 2018 • edited Loading

iFoggz Feb 27, 2018

Choose a reason for hiding this comment

iFoggz Feb 27, 2018

Choose a reason for hiding this comment

iFoggz Feb 27, 2018

Choose a reason for hiding this comment

tomasbrod commented Feb 27, 2018 • edited Loading

Pythonix commented Feb 27, 2018

iFoggz commented Feb 28, 2018

denravonska commented Feb 28, 2018 • edited Loading

iFoggz commented Feb 28, 2018

TheCharlatan commented Mar 4, 2018

TheCharlatan commented Mar 5, 2018

tomasbrod left a comment

Choose a reason for hiding this comment

tomasbrod Mar 5, 2018

Choose a reason for hiding this comment

tomasbrod Mar 5, 2018

Choose a reason for hiding this comment

tomasbrod Mar 5, 2018

Choose a reason for hiding this comment

iFoggz commented Aug 21, 2019

jamescowens left a comment

Choose a reason for hiding this comment

jamescowens commented Aug 24, 2019

iFoggz commented Aug 24, 2019

jamescowens commented Aug 24, 2019 via email

jamescowens commented Aug 25, 2019

cyrossignol commented Aug 25, 2019

jamescowens commented Aug 25, 2019

cyrossignol commented Aug 25, 2019

jamescowens commented Aug 25, 2019

iFoggz commented Sep 17, 2019

iFoggz commented Feb 27, 2018 •

edited

Loading

tomasbrod commented Feb 27, 2018 •

edited

Loading

denravonska commented Feb 28, 2018 •

edited

Loading