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

(4/5) Multiple Issues: Fix intersections after mouse button release #183

Merged
merged 46 commits into from
Oct 6, 2019
Merged

(4/5) Multiple Issues: Fix intersections after mouse button release #183

merged 46 commits into from
Oct 6, 2019

Conversation

felix-andreas
Copy link
Member

(4/5) Split up #177 in different PRs:

Needs to be merged after #182

Changes in this PR:

  • fix issue: for 3 and more monitors it was possible to create intersections between monitors (Triple-monitor setup screens not lining up #35.2)
  • check intersections after mouse button release: this makes it possible to place a monitor between to others

fix-intersections

This is a prep PR needed for the following PRs:
- snap widgets after mouse button release
- close gaps after mouse button release
- fix intersects after mouse button release
- align display_widget edges/center

Changes in this PR
- change the meaning of display_widget.delta:
 from distance of in widget units to distance in monitor/pixel units

The expression
```vala
delta_x = (int)(event.x_root - start_x);
delta_y = (int)(event.y_root - start_y);
```

led to the loss of information and as the distance in widgets units is
always less than the distance in monitor units. There no 1-to-1 mapping
was possible.

With the expression
```vala
display_widget.delta_x = (int) (diff_x / current_ratio);
display_widget.delta_y = (int) (diff_y / current_ratio);
```
a 1-to-1 mapping between the widget units and monitor units is possible
as the integer cast happens after the float division!

- rename move_display to end_grab as the signal is only emitted when the mouse button is released
- introduce new signal called `move_display` which is emitted when widget is moved
- a more concise widget snapping algorithm
- also fixes some issues when the widgets were
  perfectly aligned
- check intersections after mouse button release:
this makes it possible to place a monitor between to others
- also fix issue: for 3 and more monitors it was possible to create
intersections between monitors
Copy link
Collaborator

@jeremypw jeremypw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With three vertically stacked monitors, there is a small gap between the middle and bottom monitors
Screenshot from 2019-09-24 15 46 57

src/Widgets/DisplaysOverlay.vala Outdated Show resolved Hide resolved
@felix-andreas
Copy link
Member Author

felix-andreas commented Sep 24, 2019

With three vertically stacked monitors, there is a small gap between the middle and bottom monitors

@jeremypw, In 2ef6b0e I introduced a label which shows the exact position of the monitors. Could you use this commit to check if there is a "real" gap or the gap is only optical?

@jeremypw
Copy link
Collaborator

@andreasfelix It looks like only a pixel gap on-screen so is probably some kind of rounding error - I'll investigate further.

Jeremy Wootten and others added 17 commits September 26, 2019 10:09
…hub.com:andreasfelix/switchboard-plug-display into 2_of_5_snap_monitors_after_mouse_button_release
….com:andreasfelix/switchboard-plug-display into 3_of_5_close_gaps_after_mouse_button_release
…_5_fix_intersections_after_mouse_button_release
@jeremypw
Copy link
Collaborator

Does not compile after merging master

…se_button_release"

This reverts commit 59f7aab, reversing
changes made to 20b9006.
Copy link
Collaborator

@jeremypw jeremypw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small gaps still sometimes appear between monitors (as displayed) but I think this may be fixed by part 5/5.

More of a problem is that if a monitor is dropped on top of another, the underlying monitor moves out of the way (even if it has previously been carefully aligned). In my opinion the mis-dropped monitor should be moved to an 'allowed' position instead without moving the remaining monitors.

@jeremypw
Copy link
Collaborator

jeremypw commented Oct 6, 2019

As it looks like it is intended to drop a monitor between two others, my previous comment regarding moving the dropped monitor can be disregarded.

@jeremypw jeremypw merged commit b237537 into elementary:master Oct 6, 2019
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

Successfully merging this pull request may close these issues.

4 participants