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 the anchors and margin workflow #27559

Merged
merged 1 commit into from May 20, 2019

Conversation

@groud
Copy link
Contributor

commented Mar 31, 2019

This PR seeks to improve the usability regarding the anchors and margins workflow. It does :

  1. Remove the keep_margins_when_changing_anchors cryptic editor setting,
  2. Shows the anchors for the selected control node all the time (no need to activate helpers anymore), but keep them hidden for children of containers,
  3. allows the anchors to go lower than 0 and higher than 1, but still keep the sliders between 0 and 1. This allows, amongst other use cases, to keep the child / parent size ratio all the time,
  4. The set_anchor_preset, set_position, set_global_position and set_size function now allow for an optional keep_margins parameter. This allow moving a node to a position by modifying the anchors instead of the margin.
  5. Add a new anchor mode on the top toolbar. In this mode, moving the control keeps the margins and move the anchors instead. As its name suggests, this does allow keeping the size ration between the parent and the child.
  6. Add a new "Keep ratio" entry in the Layout menu that move the anchors to the corner of the control node (it also activates the anchor mode, so that moving the node still keep the parent/child ratio)

output

WARNING: this is more or less compatibility breaking change, as anchors are no more automatically clamped between 0 and 1 when set. Should not hurt that much though, as I think few people do modify anchors programmatically.

Closes #21080
Closes #15252

@groud groud added this to the 3.2 milestone Mar 31, 2019

@groud groud force-pushed the groud:anchor_mode branch from 3a7421c to ae03a0a Mar 31, 2019

@reduz

This comment has been minimized.

Copy link
Member

commented Apr 4, 2019

I am wondering regarding the anchors whether it may be better to move them from the viewport to the inspector, and show a little box where you can drag them around as if it was the parent area. It may be more straightforward. This is now possible to do with editor plugins, it was not before.

@groud

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2019

I am wondering regarding the anchors whether it may be better to move them from the viewport to the inspector, and show a little box where you can drag them around as if it was the parent area.

The thing is that having them in the viewport allows smart snapping the anchors. So in some situations it can be useful.
Maybe we could have both, with, everything in the inspector by default, but also the possibility to activate via a button the display onto the viewport.

@reduz

This comment has been minimized.

Copy link
Member

commented Apr 4, 2019

Something like this, which should be more contextual and discoverable..
image
Not sure if exactly like this (maybe preset could be somewhere else and some hints for left/top/right/bottom could exist), but kind of the idea, and it can be folded also together with the rest of the anchor thing.

@reduz

This comment has been minimized.

Copy link
Member

commented Apr 4, 2019

Not sure what you call smart snapping, but I think its still kind of confusing in the viewport, because maybe for center, left and right is ok, but for the rest it's still really confusing.. also in general it's just confusing.

@groud

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2019

Not sure what you call smart snapping

When you have other nodes on the screen, the anchor automatically snaps on the same axis as those nodes (when you activate the option in the snap settings).

but I think its still kind of confusing in the viewport, because maybe for center, left and right is ok, but for the rest it's still really confusing.. also in general it's just confusing.

I kind of disagree. With your approach, the problem comes when you have anything but the standard values (left, right, center, etc...). Regarding what this PR tries to solve for example, keeping the child/parent size ratio requires settings the anchors at the border of the child node, which is a lot more readable on the viewport. Also, if you want to archor the child to a specific place in the parent (let's say, 22,5% of the left side), it's a lot easier to do so on the viewport.

That's why I believe both are needed, even if the "viewport mode" should need to be enabled via a button.

@volzhs

This comment has been minimized.

Copy link
Member

commented Apr 4, 2019

I second what groud said.

@groud groud marked this pull request as ready for review Apr 4, 2019

@reduz

This comment has been minimized.

Copy link
Member

commented Apr 21, 2019

Okay then, as I mentioned, If this is fine feel free to merge

@groud groud force-pushed the groud:anchor_mode branch 2 times, most recently from 655753c to d0bcfa2 May 4, 2019

@groud groud force-pushed the groud:anchor_mode branch from d0bcfa2 to e875f05 May 13, 2019

@akien-mga akien-mga merged commit 79cc95c into godotengine:master May 20, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@akien-mga

This comment has been minimized.

Copy link
Member

commented May 20, 2019

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.