-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Select the number of items per row from slider #3405
Conversation
Just used the current controls we had, but we could probably change this for a slider. We can either add more options or add a custom option at the end for the user to specify what they want. In the end, it does simplify things by a lot, it'll be way easier to maintain, and will definitely improve performance. |
Thanks, @sroy3 ! Let's do a few changes (going forward, I know this is just a POC):
|
There are tooltips that pop pretty much instantly on these icon buttons. All plots controls are centralized there. Discovery shouldn't be hard. If we add a message, we'd have to rethink that whole menu. We have more important actions without obvious labels either. As a matter of fact, most of the actions in the extension are only one icon and a tooltip. We can try to find better icons as well if necessary. Screen.Recording.2023-03-06.at.1.33.35.PM.mov
I can do that easily (more than before). I think we had limited to 4 because on a small screen it starts being quite small and calculating break points becomes more difficult the smaller the screen is (but we do not have those break points anymore, everything is done by css). We should limit this to how much then? 10? Should we just have a numerical input instead? By the way should these icon buttons simply open a quick pick / quick input like the buttons for custom plots? We currently have 2 strategies here, custom controls and using quick pick / quick inputs. I'll generalize them at the same time (use the quick picks / inputs).
It doesn't for now. But we could maybe do some calculations to make it fit. Something like, if there are 4 items per rows and the large plot has 2 revisions in it, then place 2 plots on the row. But if there are 3 items per row or 4+ revisions, stick to 1 plot per row. This will get better if we increase the possible number of items per row. |
Yep, but I think it's not enough unfortunately. With resize the issue is that I (as a user) expect it to be naturally part of the plots (e.g. grip, an icon on the plot, etc). It's less natural and no single standard way to make it part of the menu. Thus I would advocate for explicit controls (text + something) vs buttons only. We can always optimize it back, but there is no reason for us to make it harder for people to find.
Yep, sounds good (there are some details still to clarify, but initial approach sounds reasonable to me). |
Demo was updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
color: $fg-color; | ||
} | ||
|
||
.slider { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I get what you mean, aren't both slider the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The background color of the slider in the plots could take the webview background color ($bg-color) instead of $plot-block-bg-color
.
Just a suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I'll do that as a quick follow-up, no problem
FOUR: 4 | ||
} | ||
/* eslint-enable sort-keys-fix/sort-keys-fix */ | ||
export const DefaultNumberOfItemsPerRow = 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Q] Should this be calculated based on the screen size?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure myself, just asking the question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[N] Should use screaming snake case. e.g NUM_OF_COMMITS_TO_SHOW
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[N] Should use screaming snake case. e.g
NUM_OF_COMMITS_TO_SHOW
I got confused and was wondering about this because of other variables not using this format. Will change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Q] Should this be calculated based on the screen size?
Good question. I could try this as a follow up. Currently the default vale is set in the extension, so I'd have to reset everything to undefined to then calculate it in the webview. I'd probably select the middle value by default.
@@ -42,6 +44,8 @@ export const CheckpointPlotsWrapper: React.FC = () => { | |||
menu={menu} | |||
nbItemsPerRow={nbItemsPerRow} | |||
sectionCollapsed={isCollapsed} | |||
changeNbItemsPerRow={changeSize} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there, for sure, will be some collisions. Though I don't think they'll be anything too hard to correct :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
onChange: (newValue: number) => void | ||
} | ||
|
||
export const MinMaxSlider: React.FC<MinMaxSliderProps> = ({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if there is anything that can be done about it but the slider jumps sometimes when the plot rows increase:
Screen.Recording.2023-03-08.at.8.27.14.AM.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way to solving that would be to make sure the last section is at least 100vh
which does not always look good, especially when it's empty or have very few plots. I'm wondering though if we shouldn't have one width slider for all plots instead of resizing per section.
Newest demo: Screen.Recording.2023-03-08.at.10.27.54.AM.mov |
Code Climate has analyzed commit 4990930 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 97.3% (85% is the threshold). This pull request will bring the total coverage in the repository to 95.7%. View more on Code Climate. |
Part of #2585
Demo
Screen.Recording.2023-03-07.at.1.45.23.PM.mov
Demo on a bigger screen (higher maximum number of plots per row)
Screen.Recording.2023-03-07.at.1.47.07.PM.mov
Scope