gui: Overhaul the voting UI

[cyrossignol]

This replaces the voting GUI with a new design based on #847. It adds these features:

• A header bar with a poll title filter
• Distinct tabs for "active" and "completed" polls (vs. "active" and "all" in one screen)
• A new list view for polls and minor updates for the table view
• A loading animation displayed when refreshing polls
• A "new poll received" alert banner and system tray notification
• A revamped poll results dialog and visualizations
• A "create poll" wizard with more structure than the old dialog
• A simple (for now) "submit vote" wizard

The scope of this PR does not include these proposed features:

• Tracking for polls that a wallet voted in
• Hidden/archived polls
• Poll AVW reporting and associated behavior (Show % of AVW For Polls In Wallet #2015)
• Protocol support for poll categories

The omitted items listed above need non-trivial support from core features. I chose to limit the scope of this PR to appearance and functionality changes that could be accomplished without modifying core behavior much. I'll address the other items individually in the future.

---

Voting Page

The main voting section defaults to the list view of "cards" proposed in #847. I kept the table view as well. A user can toggle between the two with the first toolbar button. The second toolbar button opens a menu used to choose a field to sort the view by (the list doesn't have sortable table headers). Unlike the table view, the list view displays the approximated remaining time for active polls next to the "vote" button (#1280). The remaining time labels update every 60 seconds, but a user still needs to press "refresh" to update the poll results because of the computational cost with the current implementation. Future optimizations may remove that limitation.

When a participant broadcasts a new poll, this page will display an alert banner under the "active" tab, and the GUI will pop-up an accompanying system notification. The notifications can be disabled in the GUI options like the transaction notifications.

The "completed" tab does not display a "vote" button for the finished polls:

The page prompts a user to press "refresh" for the first visit on either tab:

While a tab reloads, it displays an infinite progress bar animation across the top as a loading indicator:

---

Poll Results Dialog

The poll details dialog now displays the information in a unified view. Since the proposed design uses progress bars for visualizations instead of a pie chart, we can drop the Qt Charts submodule dependency.

---

Poll Wizard

I replaced the "create poll" dialog with a wizard to address feedback about invalid polls (#1725, #1788). The wizard provides some guidance for Gridcoin's poll requirements. A user begins by choosing the poll type. The selected type influences how the wizard configures the poll form, but there is no protocol behavior for these types yet. This page encourages a user to read the voting process on the wiki.

For project whitelist additions, the wizard provides a special page that introduces a user to the approval process. A user must check the box to proceed.

As an aside, I used links to avoid embedding the information in the application as much as possible. These are living documents, and it's much easier to update and translate a website than a piece of desktop software.

The "remove" option displays the current projects for convenience:

The next page prepopulates and locks some fields based on the selected poll type as described by the wiki. The page suggests a title for project polls only.

As an example, here is the page for a development poll. The "duration" and "weight type" fields lock for all but the "survey" (opinion/casual) poll type. I'm not sure whether we want to lock "duration" because the documentation describes the requirement as a "minimum" number of days, but the community seems to oppose polls longer than the minimum duration.

The improved choices editor now supports drag-and-drop to reorder the items.

Pressing the "create poll" button prompts for fee confirmation, sends the poll transaction, and displays a summary page with the poll ID for reference:

---

Vote Wizard

The vote wizard is a simple response form for now, but it provides a framework for future features like UTXO selection for vote weight control and privacy. It displays a summary page with the vote ID for reference:

Closes #1279.

[RoboticMind]

Wow that looks great! I think this would also close #1725

Minor nitpick, but I think we should probably use the term(s) opinion or casual instead of survey since that's not really terminology that's used elsewhere.

[jamescowens]

@cyrossignol I merged this along with the args PR on a test branch on my fork to try it out. So far really looks slick!

[jamescowens]

I have tested this and like it a lot.

[jamescowens]

ACK

[cyrossignol]

Thanks, all.

Minor nitpick, but I think we should probably use the term(s) opinion or casual instead of survey since that's not really terminology that's used elsewhere.

@RoboticMind I tried to future-proof the category titles a bit. If these make sense, could we update the documentation on the web site?

• Project Listing: there have been several discussions around avoiding the term "whitelist" to follow the trend in the industry. I was careful to refrain from using the term in new material.
• Protocol Development: ...since "development" is too broad, and we don't need to vote for every change to the code base.
• Governance: a more precise term than "management" which could apply to any of the categories, really.
• Survey: a more generic term that can encompass all of the free-form possibilities ("opinion", "casual", "informal", etc.) without a restrictive implication (in case old clients need to use it for a new poll category in the future).

[cyrossignol]

The "duration" and "weight type" fields lock for all but the "survey" (opinion/casual) poll type. I'm not sure whether we want to lock "duration" because the documentation describes the requirement as a "minimum" number of days, but the community seems to oppose polls longer than the minimum duration.

Need ACK/NACK on this bit still too.

CC: @barton2526 @jring-o

[jamescowens]

I think the duration should not be locked but instead should include a validation for minimum duration to follow the approved rules.

[jamescowens]

I think it is a separate question as to whether we should put a reasonable upper bound validation/clamp on the duration. I would think we need to set an upper limit for duration for all poll types. Perhaps we need to do a poll to establish that rule?

[jamescowens]

(We don't have to wait on the upper bound poll to finish this PR, BTW. We can, and should, do that in a separate PR.)

[cyrossignol]

Unlocked duration. The field is constrained to the minimum for each poll category.

[jamescowens]

ACK