Repository navigation
[Canvas] Snap to page - #36102
[Canvas] Snap to page#36102
Conversation
|
Pinging @elastic/kibana-canvas |
💚 Build Succeeded |
There was a problem hiding this comment.
@monfera The functionality works as described, this is going to be really helpful as it was surprisingly difficult to set elements along the edge without going over :)
There is a small issue that @cqliu1 and I noticed late last week where, due to some position rounding, a white 1px line can appear along the edge when in full screen mode. This feature emphasizes the issue as you would expect the alignment to go flush to edge.
Here are some screenshots:
Changing to -199px seems to resolve it
|
@ryankeairns thanks, indeed @cqliu1 and you're right about this rasterization issue. Also, the snapping makes the issue pronounced in that to work around, the user has to use the Command key to relax the snap (basically, undoing the snapping). I experimented with it a little bit in the past (not because of this edge-gap thing) and ended up not rounding the size/position pixels for some reasons encountered then. In this specific case, the rounding wouldn't always result in the elimination of the gap; in 50% of the cases, it would reify a 1px gap, because rounding can fall either way. I tried Maybe there are more, but I see these alternative solutions:
The last option would be the simplest, any idea for how to do this best with CSS/HTML? Also, is it going to cause a problem elsewhere? In short, rasterization is a minute problem on the surface but it can get tricky, and HTML is doing a less proper job with it than SVG (which has decent support). I'm not sure about timing/priorities wrt. the upcoming feature, who can decide if we shall try to solve it even if it risks the cutoff, or if it should be a subsequent discussion and PR? |
|
Ah there's a 4th option: what if we made the snap guides 1px out from the actual page bounds? A 0..1px protrusion is OK... I'll try it and push if it works out |
… presentation mode
|
@ryankeairns @cqliu1 I just pushed option 4, the 1px enlargement is unnoticeable while editing, and it appears to fix the issue |
|
I should be able to take this for a spin within the next day or so. @shaunmcgough, I added you as a reviewer as well. Any chance you'll be able to provide some feedback? |
|
@monfera that's a great and simple solution. I agree it that this rasterization issue seems simple on the surface, but probably ends up as an intricate fix. The change you implemented allows us to punt on this for a while, thanks! |
💚 Build Succeeded |
shaunmcgough
left a comment
There was a problem hiding this comment.
LGTM, great work, and works as expected.
* Typo * Snap to page borders and center lines * Feedback: avoid a potential 1px background-colored gap at the edge in presentation mode
* Typo * Snap to page borders and center lines * Feedback: avoid a potential 1px background-colored gap at the edge in presentation mode
Summary
Snap to page borders and centerline - closes #23160
Implementation note: it's achieved by simply adding a "virtual element", a rectangle with the dimensions of the page itself, to the list of snap guide shapes. This virtual element doesn't exist in any other sense of the word, only for the sole purpose of page border snap. It was enough to define a single rectangle, it's as if we were snapping elements onto the inside of a very large rectangle (assuming the element to be snapped is inside, but of course it can be outside the page too). The centerline is done automatically, as not only the borders but the center of a rectangle also acts as a snap constraint:
As seen, the centerlines of the dragged shape are also snapped to the page borders or page centerlines, in addition to the sides of the dragged shape, so it's easy to put elements in the x/y (or both) center of the page.
The
Optionresize modifier key goes well with the center snap, letting the user first snap to the desired centerline, then resize while not changing the horizontal, vertical or either center:Resize snap works too, whether orthogonal or rotated:
Grouped elements work too:
It'd be possible to solve grid snapping in a similar way:
a,b) is zeroIt'd be straightforward this way, but it's also possible to do it using the third of the elements, with rectangles where
a,bcorrespond to the grid pitch, considering that snapping isn't only done to the rectangle borders, but also to its midpoint (which is why one rectangle was enough for this PR). But it's most likely needless optimization.