network graph - show/hide panels based on window width/height
The debugwindow - network graph hides ui elements btnClearTrafficGraph, lblGraphRange, sldGraphRange when at minimumHeight, it also hides the groupBox at minimumWidth - this maximizes the dimensions of the traffic graph in these small dimensions.
https://user-images.githubusercontent.com/152159/151857512-eeaa71b3-68b3-43ff-b687-e20da896c510.mp4
commit a1bd27fa5f2c166798e331081403040027656889 rebase and set side panel to hide at 2x the minimum width of app window. Same functionality as #539 commit 874b2d8 screen cast - without other changes.
@jarolrod
Part of what I have added to my thought process is how this will translate to the mobile U/I (android/etc) - I have implemented a hybrid version of both of these approaches - but haven't posted a PR to it.
Some of my conclusions to these approaches (and the gui repo in general) - is that it may be beneficial to have a hybrid of both implementations - it would lend itself to a mobile portrait/landscape design idiom.
I may be wrong - but there doesn't seem to be enough reviewing members/contributors that have experience in the nuances of cross platform design including mobile U/I support. I don't see the Android developers reviewing this stuff to ensure up/down stream compatibility - that seems weird/negligent to me, having done mobile UI design for web, macOS/(OSX) and iOS and (Apache/Cordova) work.
I find it strange that this web interface collapses in a "responsive U/I" design - but you ask why would "we" want to do this. Who is "we"? Because most of modern UI/UX interface design has adopted this a long time ago at this point.

How about moving the current values on top of the graph (top-left?) instead?
@luke-jr - I agree - thanks for your suggestion - I will revisit this PR shortly
@luke-jr - how about a simple overlay? Note: the transparency can (obviously) be adjusted.

note: this approach removed 39 lines of code.
That looks kind of hard to read IMO. Maybe just make it the default widget background behind the text? (QFrame for borders?)
@luke-jr - This is pretty close to the original colors... I will tighten all this up - I just want to make sure the colors are good before anything else...

The correct colours to match "original" are going to vary based on the user's colour theme.
But maybe as long as we make sure the text and background have good contrast, the theme doesn't need to apply within the overlay since the graph itself is unthemed.
I do think the current screenshots are still a bit hard to read. Maybe bolding the text will do the trick?
I will look into toggling the graph (light/dark) themes based on system preferences - it may be a good "feature".
@luke-jr
I have adjusted the colors based on the global template and an accessibility audit. If we are going to be this nuanced - please actually compile/run the PR changes. [deleted]


https://user-images.githubusercontent.com/152159/154170093-70b778b2-932f-4a45-a1df-aaca11c6fb56.mov
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Conflicts
No conflicts as of last run.