Namecoin QT GUI Questions

[biolizard89]

Okay, so I've ported the old "manage names" page into Namecoin Core. I still need to go through and ensure I have a minimalistic patch against Namecoin Core (whitespace mostly).

One problem remains:

There are several locations, mostly in walletdb.cpp, where I need to do some wallet manipulations *if* we have the GUI enabled. An example is wallet/wallet.cpp:ReadKeyValue near line 600. I need to add a check for a "pending_firstupdate" strType and then restore it, so that it can be pushed out to the network at the appropriate time.

Question:

How to I include this if and only if the user is building the GUI? It looks like the old codebase used a GUI ifdef all over, which no longer exists.

I asked Luke-Jr about this a while ago; if I recall correctly, he said that the only difference between the daemon and the GUI is which files are compiled (the build scripts have 2 lists of source code files; one for the daemon and one for the GUI).

[brandonrobertz]

Okay, so I've ported the old "manage names" page into Namecoin Core. I still need to go through and ensure I have a minimalistic patch against Namecoin Core (whitespace mostly).

One problem remains:

There are several locations, mostly in walletdb.cpp, where I need to do some wallet manipulations *if* we have the GUI enabled. An example is wallet/wallet.cpp:ReadKeyValue near line 600. I need to add a check for a "pending_firstupdate" strType and then restore it, so that it can be pushed out to the network at the appropriate time.

Question:

How to I include this if and only if the user is building the GUI? It looks like the old codebase used a GUI ifdef all over, which no longer exists.

I asked Luke-Jr about this a while ago; if I recall correctly, he said that the only difference between the daemon and the GUI is which files are compiled (the build scripts have 2 lists of source code files; one for the daemon and one for the GUI).

The difference here is that the GUI code adds extra functionality: storing name_new return values and automatically sending name firstupdates. This doesn't exist at all in the text-only client and requires adding a small amount of logic to the wallet handling routine. I can't see a way around ifdefs, besides removing that functionality entirely, or leaving the restore logic in the text-only client. Thoughts?

[cassini]

Not sure if this helps, but you should first have a look at how init.cpp's HelpMessage function is used. If a GUI exists then HelpMessage it is called from utilitydialog.cpp with the constant HMM_BITCOIN_QT as the paramater ("HMM" is for "help message mode"). If there is no GUI then HelpMessage is called from bitcoind.cpp with the constant HMM_BITCOIND. (The constants HMM_BITCOIN_QT and HMM_BITCOIND are defined in init.h, see enum).

The build process determines whether bitcoind.cpp or utilitydialog.cpp is in use eventually, e.g.

without GUI:

Code: Select all

./autogen.sh
./configure --without-gui   # ( --without-gui is equivalent to --with-gui=no )
make

with GUI:

Code: Select all

./autogen.sh
./configure --with-gui=qt5
make

[domob]

A brief comment from my side: If the code in question is not directly GUI-related (e. g., depending on Qt) but does general wallet handling, I see no big deal in adding the functions always even if they are then only used from the GUI. In respect to the pending firstupdates, for instance, those could (maybe in the future) also be useful for RPC. (Not concretely planned, but it is conceivable.) Thus I see no problem adding the logic there even without #ifdef's, as long as it really belongs there logically.

[biolizard89]

A brief comment from my side: If the code in question is not directly GUI-related (e. g., depending on Qt) but does general wallet handling, I see no big deal in adding the functions always even if they are then only used from the GUI. In respect to the pending firstupdates, for instance, those could (maybe in the future) also be useful for RPC. (Not concretely planned, but it is conceivable.) Thus I see no problem adding the logic there even without #ifdef's, as long as it really belongs there logically.

Agreed; functionality like storing name_firstupdate transactions doesn't seem bad to have in the daemon. Explicitly exposing it in the daemon's RPC interface seems to be a low priority, but I don't see any reason to make things more complex just to avoid having that code in the daemon.