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 overlap handling. #90

Open
cameron-toy opened this issue Oct 2, 2020 · 0 comments
Open

Improve overlap handling. #90

cameron-toy opened this issue Oct 2, 2020 · 0 comments

Comments

@cameron-toy
Copy link
Collaborator

cameron-toy commented Oct 2, 2020

The Problem

Overlap handling isn't very good, and outright fails in certain cases.

Background

Currently, dashboards have rudimentary overlap detection and resolution for outputs. Placing one output on others will cause the other outputs to move up/down relative to the placed widget so they're no longer overlapping.

overlap

If placing a widget would cause the other widgets to move beyond the edge of the dashboard, the dashboard will be expanded to accommodate them. This is currently broken for the top edge, and causes a gap between the placed widget and the overlapping widgets.

top_edge

Another annoying issue arises when one wants to align two outputs horizontally in free mode. Here, a small overlap can cause a chain reaction of moves that can really mess up a layout.

Finally, the current algorithm compares the area covered by a widget to the area covered by every other widget every time a widget moves to find overlaps. This inefficiency causes slowdowns with large layouts

The Solution

An improved overlap handling algorithm that is:

  1. Intuitive. It should be obvious where outputs will move if there's an overlap, or at least some visual indication.
  2. Unobtrusive. Overlapping outputs should move a minimal amount and for small overlaps it should be difficult to tell anything has happened at all.
  3. Fast. Overlap resolution should happen instantly.

Additional notes: I think some amount of snap-to-edge should replace small overlaps, and that resizing shouldn't occur at any point as part of overlap handling. Also, I'm open to solutions that involve horizontal movement.

Some alternate algorithms are described here: https://mikekling.com/comparing-algorithms-for-dispersing-overlapping-rectangles/

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

1 participant