This PR:
- makes an “alternating row colors” feature in the Peers tab switchable to satisfy all users with different tastes.
- is a follow up of #298
- is an alternative to #306
Screenshot:
804@@ -805,6 +805,16 @@
805 </layout>
806 </widget>
807 </item>
808+ <item>
809+ <widget class="QCheckBox" name="peersTabAlternatingRowColors">
810+ <property name="toolTip">
811+ <string>Turn on/off row color alternating for both "Peers" and "Banned peers" tables in the Peer Tab.</string>
0 <string>Alternate the row colors for the "Peers" and "Banned peers" tables in the Peers tab.</string>
809+ <widget class="QCheckBox" name="peersTabAlternatingRowColors">
810+ <property name="toolTip">
811+ <string>Alternate the row colors for the "Peers" and "Banned peers" tables in the Peers tab.</string>
812+ </property>
813+ <property name="text">
814+ <string>Alternate row colors in the Peers Tab</string>
I’m sorry for being picky..! Or a diva… or whatever it is…
Just to clarify, I think my preferences are, in order of preference-
- No stripes by default, but a config option somewhere more hidden than this proposed option (maybe in a config file instead?)
What is the rationale of hiding a visual appearance option from users?
The bitcoin.conf
is not dedicated for such options.
So far we had alternate rows and nobody complained AFAIK. If we add this option I think it should affect all tables, not only peers table.
Concept ACK figuring out the scope of appearance settings. Until then NACK, this particular option seems to have no grounds and might lead to similar pull requests.
I agree with this
If we add this option I think it should affect all tables, not only peers table.
Also, this sets a good precedent for continuing to make the GUI user configurable.
ACK 081842d6a735a85e5611ab36703b63f8632f7f4b
Thanks for adding this option and tidying up the spacing in optionsdialog.ui
If we add this option I think it should affect all tables, not only peers table.
This can be addressed in a follow-up PR.
Start up GUI:
Start | Enable Option |
---|---|
Restart GUI:
Start: Setting Persists ✅ | Disable Option |
---|---|
Tested ACK 3231689fa9b379e2c214a69b6694340f22c2a7ae modulo that it would be nice for the change to occur immediately when checking/unchecking the option and I would squash the last 2 commits.
Wishlist:
ACK 84be484
Tested on Arch Linux Qt 5.15.2
, macOS 11.3 Qt 5.15.2
, and cross-compile to Windows 10
.
Notes on commits:
clang-format-diff.py
gives me the same diffScreenshots:
Start | Enable |
---|---|
Restart | Disable |
---|---|
5@@ -6,8 +6,8 @@
6 <rect>
7 <x>0</x>
8 <y>0</y>
9- <width>560</width>
10- <height>440</height>
11+ <width>646</width>
Nit
there’s not really a reason to change the size here. I guess this is a good place to answer a question:
“When adding new settings, should we maintain a certain level of padding between the last setting option and its enclosing box?”
Use PR Size | Use Master Size |
---|---|
there’s not really a reason to change the size here. I guess this is a good place to answer a question:
The reason is that successive openings and closings of the optionsdialog.ui
in Qt Designer won’t suggest size changes.
89+ Prune, // bool
90+ PruneSize, // int
91+ DatabaseCache, // int
92+ SpendZeroConfChange, // bool
93+ Listen, // bool
94 OptionIDRowCount,
Nit in 217d42b7465bf210511ef6cdff0475eb0a9e078c
While here, you could document the type here is int
.
Additionally, if you have to retouch, you could rename the commit from:
gui: Add "Alternating Row Color" settings for the Peers Tab
to:
qt: Add "Alternating Row Color" settings for the Peers Tab
While here, you could document the type here is
int
.
I don’t think it is required to document the type of a counter, as it is not an option id.
So far we had alternate rows and nobody complained AFAIK. If we add this option I think it should affect all tables, not only peers table.
Until then NACK, this particular option seems to have no grounds and might lead to similar pull requests.
Also NACK. First, alternate rows are added, then an option is added to disable it. Do not start option bloating because of groundless “tastes” of some users. Keep it simple (and unflexible).