You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Users may be interested in seeing more stats than can fit into the small widget space. For instance, they might want to see a table view of how much they've played each day for the last month, and that wouldn't fit in the current main widget layout.
I'm interested in implementing a tab system, where each Statistic could have a detailedExtendedDisplay property (I'm not attached to this specific name) which would return a TabCreator. Then each Statistic with a detailedExtendedDisplay would get a new tab added to the window, and no tabs added for a Statistic that doesn't have an extended display.
I actually tried implementing this using just two tabs - the main content tab, and a single other tab with a dropdown that would let you select which extended display you'd like to view. Unfortunately, there isn't a concept of visibility hierarchy,(e.g. there's no way to set a parent horizontal visibility to "none" and have all its children also be turned to visibility none), so creating separate tabs is the only way I see to do this.
Another way to display more details could be to make the main window larger to fit bigger widgets. I like this less because I like the uniformity of the current createWidget() output, and it might be challenging to figure out how to add future new widgets if the main window is clogged up with these extended details.
Included is a proposed screenshot of what the tabs could look like. The flexUI window auto resizes the window height based on the size of the content in it, which I very much like. If it wasn't desirable, a static height could be used.
Would you be interested in seeing a PR of this, and if so how would you prefer I submit since I see there being 3 parts: a potential new Statistic, the architecture for an extended display, and some potential extended display implementation ideas.
The text was updated successfully, but these errors were encountered:
Sounds cool! I remember considering this at one point, but since there was only one statistic, it seemed overkill. I was thinking there could be a tab specifically for settings where the Pause Statistics and Reset Statistics would reside.
I definitely see the concern where if there are a bunch more stats, it would become more cluttered. Ideally, we would only need to worry about this in terms of a UI standpoint, and not have this affect any data being stored (so as to not create more legacy functionality).
Users may be interested in seeing more stats than can fit into the small widget space. For instance, they might want to see a table view of how much they've played each day for the last month, and that wouldn't fit in the current main widget layout.
I'm interested in implementing a tab system, where each Statistic could have a
detailedExtendedDisplay
property (I'm not attached to this specific name) which would return aTabCreator
. Then each Statistic with adetailedExtendedDisplay
would get a new tab added to the window, and no tabs added for a Statistic that doesn't have an extended display.I actually tried implementing this using just two tabs - the main content tab, and a single other tab with a dropdown that would let you select which extended display you'd like to view. Unfortunately, there isn't a concept of visibility hierarchy,(e.g. there's no way to set a parent
horizontal
visibility to "none" and have all its children also be turned to visibility none), so creating separate tabs is the only way I see to do this.Another way to display more details could be to make the main window larger to fit bigger widgets. I like this less because I like the uniformity of the current createWidget() output, and it might be challenging to figure out how to add future new widgets if the main window is clogged up with these extended details.
Included is a proposed screenshot of what the tabs could look like. The flexUI window auto resizes the window height based on the size of the content in it, which I very much like. If it wasn't desirable, a static height could be used.
Would you be interested in seeing a PR of this, and if so how would you prefer I submit since I see there being 3 parts: a potential new Statistic, the architecture for an extended display, and some potential extended display implementation ideas.
The text was updated successfully, but these errors were encountered: