This is a read-only archive of the Framer Community on Facebook.

What is Framer? Join the Community
Return to index
Johannes Eckert
Posted Aug 20 - Read on Facebook

idea for Framer.js: when changing superLayers, I'd wish there would be a way to keep the object's absolute visual position (layer.screenFrame?) the same. I tried to use convertPoint but it wasn't apparent to me how to use that. Could there be a method like
changeSuperLayer(destinationLayer, keepPosition)

use case: when dragging a layer with an object, after some threshold I want to not move the object anymore (but still drag the frame), so I put the object outside the layer I'm dragging, but I need to re-position it to the same place as before, creating some furious math to make this happen.
or is there just a clever trick I'm not seeing?


Johannes Eckert

or are there two lines that make this work with screenFrame? à la:
tempFrame = layer.screenFrame
layer.superLayer = otherLayer
layer.frame = tempFrame

would that make the object just keep it's position when changing superLayers, Koen Bok?

Seoh Char
if in hurry, use this. but i'm not sure that it is enough to be safe. because undocumented feature could cause infinite loop.

Koen Bok

Here is an example:

You've inspired me to change the layer.screenFrame() to a property that you can get/set.

Maybe I'll even go as far as your suggestion to keep it on the same visual position on the screen if you change superLayers. But I have to think that through more.

Koen Bok

Tisho, Josh, Elliott Noah what would you guys think about re-setting the frame on a superLayer change to the previous screenFrame? The result would be that if you change a layers superLayer the position on the screen will always stay the same, just the x and y would change.

I think this might be smart because I've often witnessed confusion when people change superLayers and the coordinate system suddenly changes with it.

The one thing it wouldn't solve is when the new position (same position on the screen) would be clipped by it's new superLayer. We have that now too.

Another thing that I once thought about (but decided not to do) is to always reset x and y to 0, 0 on a superLayer change.

Josh Puckett

Koen, I believe that's what people usually intend. It's similar in Photoshop/Sketch, if I group a layer or move it up and down in the tree, it's attributes don't change. Potentially I see conflicts where you are animating/changing attrs, but because you changed a superLayer it's now off. I'd also try and not be super clever with it, as this can lead to lack of transparency as to what's going on (so changing the X and Y to what they now actually are is good).

Andreas Wahlström

Koen Bok maybe clip should default to false? that would make it more predictable.

Elliott Kember

I'd like this. I'm always wrapping layers in other layers so this would save me time resetting using the parent's x and y.

Tisho Georgiev

I'm not sure about this. It makes sense for layers coming in from the importer that already have a position on screen. When you then want to change containers of a layer, you're more likely to want to keep its absolute position intact. All good.

For layers that you create yourself, though, it can be somewhat confusing. Let's say I have a containerA layer at 100, 100, and I write this:

layerA = new Layer x: 0, y: 30, superLayer: containerA

What's the position of layerA in this case? 100,130 or 0,30? If I'm creating the layers myself and I know they're going to be nested inside a container, I'll most likely write their positions relative to the container's 0,0. In this case, superLayer's new behavior will get in the way.

As a compromise, I'm wondering if a function like layerA.moveTo(containerA) isn't more along the lines of what we're looking for. Something that isn't pretending to change one property but is actually changing more behind the scenes.

Johannes Eckert

Tisho is right, when creating layers, I wouldn't expect this. could this only apply when you -change- the superLayer, not when creating a new layer?

Koen Bok
Mike Feldstein

Would it be difficult to make this animateable?

Koen Bok

Mike: you can just calculate a screen frame with Utils.convertPoint and throw that into an animation right? Or am I not understanding you correctly?

Mike Feldstein

Mostly yeah that would work. I was just doing something in a really poor way yesterday.

Read the entire post on Facebook