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

Improve canvas grid and zooming behavior #26

Open
thachmai opened this issue Nov 8, 2015 · 1 comment
Open

Improve canvas grid and zooming behavior #26

thachmai opened this issue Nov 8, 2015 · 1 comment

Comments

@thachmai
Copy link
Contributor

thachmai commented Nov 8, 2015

The canvas grid is currently fixed from [-10,-10] to [10,10] with the grid lines always visible.

Zooming is currently not restricted in anyway. You can manage to "lose" the position of the grid by accident.

Some additions to the current behavior could improve usability:

  • Ability to the turn grid on/off.
  • A strong gridline for 10s of units. A less visible line for single increments.
  • Show the grid for the whole canvas.
  • Constraint the zoom and panning to a restricted plane: either [-100,-100] to [100,100] or double the size of the current sketch, whichever is larger.
@electronicwhisper
Copy link
Collaborator

Great. You'll see there's a hack to hide the grid; I quickly put this in because I needed it for a presentation. But I think this visibility state should just be in the Layout model that you made for #24.

As for the button to toggle visibility of the grid, the menubar is starting to get crowded. We can put an icon next to the full screen icon I guess.

Your suggestions in bullet points 2 and 3 sound good.

4 sounds good too. Finding the size of the current sketch takes a bit more work. We need to be able to determine the "bounding box" for a diagram. I have wanted to do this so that we could show the create panel thumbnails nicely cropped. To do this, we should add a method boundingBox to Graphic. So a graphic can render, hit detect, or figure out its bounding box.

I would say 1-3 are a good unit of work. 4, along with the bounding box implementation, should be its own PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants