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
is your feature request related to a problem? Please describe.
I've noticed that a lot of the interface uses hardcoded values to define paddings, margins and positioning. You've noted in another issues that there was often issues opened by users about unexpected layouts, and I would tend to think that there's a link between these two. Also, contributing to and adjusting the interface is not easy when every distance and position is hardcoded.
Describe the solution you'd like
Progressively transition updated components to flexbox. Flexbox is a native css feature that allows dynamic setting of margins, sizes, positions and page flows.
Additional context
This issue is only intended to be closed with a positive or negative answer. Subsequent issues will be opened for any modified component.
transitioning the control component to flexbox
before flexbox:
visual, manual, hardcoded adjustment of the red boxes margins to center the arrows
distance selection not actually centered
after flexbox:
cleaner content handling
boxes are arithmetically centered and will flow depending on the width and height
an additional jog control can be added without changing any margins, paddings or widths (no css modified)
The text was updated successfully, but these errors were encountered:
I think you understood me wrong there. The issues a couple of users have reported are due to a completely wrong resolution - i.e. OctoDash is rendering in 1920x1080, and the screen is displaying only the top left 800x480 pixels.
Nevertheless flexboxes are super nice, I haven't really worked with them much when I started OctoDash, which is why I used vw and hw (which are at least somewhat dynamic compared to px units).
So it would definitely be nice to use more flexboxes, I wouldn't put this at high priority though. If someone needs to do UI changes to a component anyways (like you to the control screen) it would be nice to replace the existing layout with flexboxes, but I think we don't need to replace everything with flexboxes just because now. It might not be the cleanest way but I haven't heard of any issues regarding the actual layout rendering wrong so far and there are still a lot of other open issues :)
is your feature request related to a problem? Please describe.
I've noticed that a lot of the interface uses hardcoded values to define paddings, margins and positioning. You've noted in another issues that there was often issues opened by users about unexpected layouts, and I would tend to think that there's a link between these two. Also, contributing to and adjusting the interface is not easy when every distance and position is hardcoded.
Describe the solution you'd like
Progressively transition updated components to flexbox. Flexbox is a native css feature that allows dynamic setting of margins, sizes, positions and page flows.
Additional context
This issue is only intended to be closed with a positive or negative answer. Subsequent issues will be opened for any modified component.
transitioning the control component to flexbox
before flexbox:
after flexbox:
The text was updated successfully, but these errors were encountered: