No Branch/Tag Specified
chat
custom_themes
danger
dev
duke
importviewkey
master
no_mining_until_synced
old_duke
onryo
recurring
0.4.0
0.4.1
0.4.2
0.4.3
0.5.0
0.5.1
0.5.10
0.5.11
0.5.3
0.5.4
0.5.5
0.6.0
0.6.1
0.6.10
0.6.11
0.6.2
0.6.3
0.6.4
0.6.5
0.6.6
0.6.7
0.6.8
0.6.9
0.7.0
0.7.1
0.7.2
0.7.3
0.7.4
0.7.5
0.7.6
0.7.7
0.7.9
1.4.2
v0.1.5
v0.1.6
v0.1.7
v0.1.8
v0.1.9
v0.2.0
v0.2.1
v0.2.2
v0.2.3
v0.2.4
v0.2.5
v0.2.6
v0.2.7
v0.2.8
v0.2.9
v0.3.0
v0.3.1
v0.3.2
v0.5.2
v0.5.6
v0.5.7
v0.5.8
v0.5.9
v0.7.5
v0.7.6
v0.7.7
v0.7.8
v0.8.0
v0.8.1
v0.8.2
v0.8.3
v0.9.0
v0.9.1
v0.9.2
v1.0.0
v1.1.0
v1.2.0
v1.3.0
v1.3.1
v1.4.0
v1.4.1
v1.4.2
Labels
bounty up to 500 HUSH 2001-5000 bounty
bounty between 2001 and 5000 HUSH 501-2000 bounty
bounty between 501 and 2000 HUSH arm
something doesn't work on arm beginners
for new developers bug
may or may not be a bug build
problems building documentation
not enough information feature
new feature high priority
high priority i2p
related to i2p low priority
low priority medium priority
medium priority question
something is not clear release
release label or issue related to it tor
related to tor translation
translation update windows
related to windows wontfix
this won't be fixed
Apply labels
Clear labels
0-500 bounty
bounty up to 500 HUSH 2001-5000 bounty
bounty between 2001 and 5000 HUSH 501-2000 bounty
bounty between 501 and 2000 HUSH arm
something doesn't work on arm beginners
for new developers bug
may or may not be a bug build
problems building documentation
not enough information feature
new feature high priority
high priority i2p
related to i2p low priority
low priority medium priority
medium priority question
something is not clear release
release label or issue related to it tor
related to tor translation
translation update windows
related to windows wontfix
this won't be fixed
No Label
0-500 bounty
2001-5000 bounty
501-2000 bounty
arm
beginners
bug
build
documentation
feature
high priority
i2p
low priority
medium priority
question
release
tor
translation
windows
wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Currently SD or SDX can be used by using a different binary name. This was the easiest way to allow for certain workflows, such as "I only care about DragonX, I want to click an icon and a DragonX GUI wallet to start" OR "I only care about Hush, I want to start just the Hush GUI wallet". Some people might have both a Hush + DragonX full node running on the same machine, so looking at which full node is running would not work when both are running.
A dedicated binary also means you can run SD + SDX at the same time.
Making users download/install both SD + SDX binaries is somewhat wasteful of bandwidth and disk space for certain users. If a user wants to run both SD and SDX (but not at the same time) we could offer an option to change between them at run-time.
It could be that nobody would use this feature and it's not worth the time to do it. Would any Hush devs use this feature or do you prefer to have dedicated binaries with the ability to run SD+SDX at the same time?
I don't mind the dedicated binaries and think they may be better for marketing and distinguishing which coin you're using. I'd still find it useful.
Trying to envision how it would work from the GUI with stopping/starting node and detecting which is running. Will SD always default to HUSH and SDX always default to DRGX when opening? Would there be a more advanced check to save and then display the GUI for the last changed coin?
Occasionally the node doesn't always stop when closing GUI so that's something to think about. You wouldn't want to open SDX expecting to see DRGX but then see HUSH because the HUSH node is still running. At the same time, if you last changed to HUSH in SDX, you might not want to see DRGX when re-opening.
@fekt you bring up some good points. There are a lot of edge cases to deal with if this feature existed, and we could come up with some solution to them, but they likely would not be intuitive for many users. I don't think this feature is worth implementing. We have plenty of other stuff that is much more important to work on.