Skip to content
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

progressive rewrite of hardcoded vw values to dynamic flex values #1622

Closed
pciavald opened this issue Mar 28, 2021 · 2 comments
Closed

progressive rewrite of hardcoded vw values to dynamic flex values #1622

pciavald opened this issue Mar 28, 2021 · 2 comments
Labels
discussion Issue needs to be discussed further

Comments

@pciavald
Copy link
Contributor

pciavald commented Mar 28, 2021

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

image

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)

image

image

@pciavald pciavald added the enhancement New feature or request label Mar 28, 2021
@pciavald pciavald mentioned this issue Mar 28, 2021
@UnchartedBull
Copy link
Owner

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 :)

@UnchartedBull UnchartedBull added discussion Issue needs to be discussed further and removed enhancement New feature or request labels Mar 29, 2021
@pciavald
Copy link
Contributor Author

Ok perfect, exactly what i thought too. Can you point out to an issue opened by a user of what you're talking about? i can take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Issue needs to be discussed further
Projects
None yet
Development

No branches or pull requests

2 participants