Lock children – Context Toolbar / Menu bar / Shortcut / Help

[reminous]

+1  for shortcut or global right mouse contextual click also

[thomaso]

Strange, although "Lock children" is not a setting for selected layer(s) only but a document-wide setting – affecting all those children in the entire document if checked for just one of them – the concept of its interface accessibility seems to have a lot less general but instead very selective, specific situations in mind. I still can't imagine after years using this feature why its UI does show up exclusively context related and in the Context Toolbar only (and, additionally, there in its hidden off-area at the right end).

Instead, I would expect access to "Lock children", not only because of its document-wide effect, to appear as a permanently listed & actually permanently selectable option (independent of a layer selection) in the menu bar, e.g. under Layer -> Lock..., where it would also additionally allow the missing key shortcut.

[greyscale]

Thomaso, I think you're talking about something different. We're discussing the Lock Children checkbox that is found at the far right of the Contextual Toolbar. It most definitely affects only the selected layer.

 

[thomaso]

On 2/24/2022 at 9:24 AM, greyscale said:

It most definitely affects only the selected layer.

Maybe we differ in the understanding of "it affects":

• Concerning an object change done to a parent layer it correctly affects only selected parent layer(s).
• Concerning its activation / deactivation it affects all according parent layers in the current document.

So, if you select parent layer A it affects its child A.1 and does not affect any other not selected parent /child layers. But if you then select a parent layer B then B has the checkbox ticked as well, so now a change of B will have B.1 locked, too. If you now untick the checkbox with B still selected and then select A, then also A has the checkbox unticked.

This way it works a.) like a document setting and is independent of layer selection, although it requires b.) having a parent layer selected to make it show up in the UI & accessible at all. Concerning a.) it behaves like a document property (as e.g. transparency grid on / off), concerning b.) it is more like an object property (as e.g. stroke on / off, which reminds its most recent setting for new object creation).

[ashf]

+1 for the shortcut

[fde101]

On 2/24/2022 at 3:24 AM, greyscale said:

Thomaso, I think you're talking about something different. We're discussing the Lock Children checkbox that is found at the far right of the Contextual Toolbar. It most definitely affects only the selected layer.

It is a global setting which is a setting of the tool rather than a property of the layer itself.  It has an effect on how the tool interacts with children of the layer which is being operated on by the tool.  It has an effect on ALL layers in that if you then take the tool and apply it to a different layer (which has children) it will still be in effect for that layer as well, but it also has NO effect on ANY layers in that changing the setting in and of itself does NOTHING to any of the layers - it causes the move tool to behave differently and thus is a property of the tool.

Thus, it makes perfect sense that it would be in the context toolbar where other tool properties can be found.

[thomaso]

6 hours ago, fde101 said:

Thus, it makes perfect sense that it would be in the context toolbar where other tool properties can be found.

Thus? Perfect? – Considering the range of generally used places in the UI could imply various locations for "Lock Children":

Transparent Background –> main menu & Context Toolbar
Preview Mode –> main menu & Toolbar
Show / Hide Guides –> main menu & Preview Mode
Highlight Fields –> main menu
Edit All Layers –> Layers Panel button
Include Margins (spread property) –> Context Menu (right-click pop-up)
Customize Toolbar –> main menu & Toolbar + Context Menu

If you say "but these are no tools": Also "Lock Children" is not really a tool property (as e.g. colour is for brush) but rather a temporary property of all child layers which gets set document wide and with the option to toggle … exactly like the samples above. That it becomes effective with the use of the Move Tool seems to give you the impression to be a tool property, but note, also the layer lock becomes effective with the use of a tool only, as probably any action done to layers requires a tool, panel or menu. From that perspective "Lock Children" could also be an item in the context menu (right click) or a button in the Layers Panel … but at least it could be an entry in the Main Menu > Layer. – Perfect!

[fde101]

6 hours ago, thomaso said:

Also "Lock Children" is not really a tool property

Yes, it is: when checked the tool works only on the layer that is being specifically targeted; when unchecked the tool works on all of the children of that layer also.

Furthermore, if I switch to a shape tool while it is still checked then try to move a shape with child layers, the child layers move along with the shape.  If I then switch back to the move tool, the option is still enabled and only the parent layer is moved.  The "lock children" feature is ONLY in effect for the move tool, making it a property of the tool.  If it were a property of the layers, it would be in effect for the other tools as well.

 

6 hours ago, thomaso said:

also the layer lock becomes effective with the use of a tool only

The "lock children" feature only works for one specific tool and is in effect for all layers with children when enabled; this makes it a property of the tool.  The layer lock feature works across all tools which can transform a layer and is in effect only for the layer it is applied to; this makes it a property of the layer.

 

6 hours ago, thomaso said:

at least it could be an entry in the Main Menu > Layer

So could preferences, or quit application, but that doesn't mean they belong there.  This is NOT a property of the layer, but of the tool, so it does not belong in the Layer menu.  It doesn't really fit ANY of the menus that currently exist in any of the Affinity apps, but if I had to pick one, I would argue that the Select menu is the best (still bad) fit.

[thomaso]

@fde101, I can follow your thoughts but they appear too narrowed or simplified to me. Using a hammer for a nail doesn't make the nail a property of the hammer.

Not only does a layer lock not prevent from any change done to a locked layer (for instance we can use the Transparency Tool, the Gradient Tool or the Image Place Tool for a selected layer even if it is locked) – but also the property of 'Locked Children' is done to the children, not to the tool, like the layer lock is done to the layer, not to the panel. The tool or panel are just the UI items we use to set the state of being locked – but these UI items could alternatively be others and elsewhere.

I think you agree that a gradient is a property of an object, not a property of a certain tool, although the Gradient Tool can get used as one of several ways to apply a gradient. Accordingly transparency is a property of an object, not of a tool – though it may get set by the Transparency Tool this property can also get set by a mask or directly in the Layers panel. The Transparency Tool itself doesn't become transparent like the Move Tool doesn't become locked if you use it to activate "Lock Children". Also colour transparency is not a property of the colours panel, though it can get set there, in the layout it may even not be visible if a shape has a transparent fill colour assigned or an opaque fill instead but layer or effect or tool transparency.

So the Lock Children property seems to be a special property, because it affects all child objects in the document, regardless of whether they are currently selected while it gets activated. This puts it between other properties (such as Color, Opacity, Contour) that require an object to be selected, and properties that affect the entire document without requiring an object to be selected when it is activated, such as the various view options (transparency grid, guides, etc.).

This particular nature of the Locked Children property is the reason for a special treatment within the user interface. Since it affects all possible child objects when activated, it is useful to be able to set it in an object independent UI hierarchy, e.g. via menu and/or keyboard shortcut. This attitude of affecting all objects also eliminates the current requirement that a parent layer must be selected for it to be enabled/disabled at all, which in fact is a really weird current condition.

[fde101]

4 hours ago, thomaso said:

it affects all child objects in the document, regardless of whether they are currently selected while it gets activated

Not quite true.  If I create a hierarchy of three objects, with a rectangle which has a ellipse as a child and a cat being a child of the ellipse, then the ellipse is a child object as it is a child of the rectangle.  If I select the ellipse and have the lock children property enabled, I can still move it - it is not locked in place, even though it is a child object.  Only the cat is locked in place, because it is a child of the object which is selected to be moved - the ellipse is not affected by the setting.

The setting is not applied to all child layers - only to layers of the object which the tool is acting on, as the tool does not attempt to modify them due to its setting being enabled.

This is equivalent to the way that the transform mode of the node tool has an effect on the way that the tool behaves when nodes of an object are selected - the mode does not alter the object itself, but rather the way the tool behaves, and is therefore a property of the tool, not of the object or the nodes.

 

That said, we can argue the semantics in circles all day and if you've made up your mind that you want to perceive it as a strange offshoot of a layer property rather than the more obvious explanation of it being a tool property (which it clearly is), there is little value in arguing the point.

The actual request was for a keyboard shortcut to be added to toggle the property, and I agree that would be useful.

Rather than adding it to a context menu or somewhere else in the menu bar though (as no other tool properties appear to be there that I can find), I would suggest it could be made to fit into the context toolbar on a reasonable display size (mine is a 23" and this would work) by changing it to an icon instead of a checkbox with text, as most of the others are on the toolbar already.  Do the same with "Single radius", "Absolute sizes" and the like, and maybe you could squeeze it in to a slightly smaller one yet?

Another interesting possibility would be to be able to configure the context toolbar to be two rows, so that those working on narrower screens (laptops and the like) could configure it that way and see more of the content at once without having to click the arrow thing on the end.

[thomaso]

6 hours ago, fde101 said:

there is little value in arguing the point.

You started debating this question, not me. – When a Key is a Tool to a Lock of a door, is being locked a property of the key? I'd say "the door is locked", not "the key is locked". And I am sure you wouldn't say the latter, either. So 'locked' is the property, while the tool just allows to set the property.

6 hours ago, fde101 said:

I agree that would be useful.

Thank you! That's all this feature request is made for: increasing usability. And, yes, a shortcut key would be only 1 possible way to achieve easier accessibility of "Lock Children".

By the way: if you select a parent layer + any single layer (no parent) then the "Lock Children" checkbox immediately becomes accessible more directly. Thus a layer without child (as the 2nd selected object) causes the lock option to occur instead of being hidden in the bar's outer space – Fun fact?

[fde101]

41 minutes ago, thomaso said:

You started debating this question, not me. – When a Key is a Tool to a Lock of a door, is being locked a property of the key? I'd say "the door is locked", not "the key is locked". And I am sure you wouldn't say the latter, either. So 'locked' is the property, while the tool just allows to set the property.

True that being locked would be a property of that door, but what you are suggesting by calling the "lock children" option a global property of the layers is the equivalent of saying that every door in the world is locked simultaneously by the same key, and that doesn't quite mesh with the reality of what is going on.

If I drill a hole in a piece of wood, and the wood is up against something else that then receives a hole because the bit pushes through the first piece, does that mean that having a hole of that diameter is a property of a piece of wood sitting on the other side of the room?

[thomaso]

30 minutes ago, fde101 said:

a global property of the layers is the equivalent of saying that every door in the world is locked simultaneously by the same key

Why that? The need of energy as a 'global' property of vehicles to move does not mean all vehicles "in the world" use the identical energy, even not the same type of energy. (btw, where did I talk about 'global' in this thread? In fact the property of being locked is a document-wide property – but this doesn't say it affects all instances or all features of a document. That fact that "locked children" affects the use of the MoveTool doesn't influence the locked state of children: they are still locked, but not for all actions or features. Like the Layers Lock doesn't affect all properties of a locked layer: if selected you can e.g. colour it while you permanently see its active locked state in the layers panel. This layer is locked – even if not locked for everything.

If you lock your car + unlock your home, then entering the home doesn't influence the locked state of the car and your car will be locked independently of where, when and how you locked it. Locking can be caused by a mechanical key, a wireless key, a software used from home … The car stays locked even if you then wash or paint it or change its tires, only the doors are affected, though we are used to say "the car is locked", not its tires, windows. If you open the windows before locking the car then you even can enter the car without unlocking it, its doors remain locked while you may move in & out.

52 minutes ago, fde101 said:

If I drill a hole in a piece of wood, and the wood is up against something else that then receives a hole because the bit pushes through the first piece, does that mean that having a hole of that diameter is a property of a piece of wood sitting on the other side of the room?

Each of the two materials (~ layers) has a hole. So both of them have the property of having a hole. This property is completely independent of HOW they got the hole. Their holes are not a property of a tool, e.g. a drill. These are their holes.

[prophet]

I'm really enjoying this epic metaphor battle. Carry on.

[fde101]

1 hour ago, thomaso said:

Each of the two materials (~ layers) has a hole. So both of them have the property of having a hole. This property is completely independent of HOW they got the hole. Their holes are not a property of a tool, e.g. a drill. These are their holes.

Exactly!

The fact that those two pieces of wood have a hole does not mean that the piece sitting across the room from them does.

 

When the "lock children" option is enabled, it tells the tool that when it is working on one layer, it should not change the layers which are children of that layer.  The fact that the tool is used on parent layer A does not mean that parent layer B is automatically modified.

The transform (position, scale, rotation and shear) of each layer is a property of that layer.

The fact that the move tool, when its "lock children" option is enabled, only changes the transform of the parent layer, does not mean that any property of any other layer is impacted - just the opposite: it prevents the transform of a child layer from being adjusted relative to the page.

The "lock transform" feature modifies the behavior of the tool and tells it to modify the transforms of a more limited set of layers than it would when that feature is not in use.  This makes it a property of the tool.

[thomaso]

58 minutes ago, fde101 said:

The transform (position, scale, rotation and shear) of each layer is a property of that layer.

We get closer.
Not-transform is a property of the layer, too:
If you create a rectangle shape its initial angle is = 0º. Now, also this 0º is a property of this rectangle. Its angle was not transformed yet.
The values in the Transform Panel show properties of layer objects numerically, they never show properties of the panel or of any tool.

26 minutes ago, fde101 said:

(...) The "lock transform" feature modifies the behavior of the tool and tells it to modify the transforms of a more limited set of layers than it would when that feature is not in use.  This makes it a property of the tool.

If the lock tells the tool how to behave – how can the lock be a property of the tool?

If a key tells a door not to open – is the lock a property of the key, or of the door?

If light makes a plant grow – is grow a property of light? If of light: who is growing?

[fde101]

5 hours ago, thomaso said:

Not-transform is a property of the layer, too:

Yes, in the form of the transform lock on the layer itself.

 

5 hours ago, thomaso said:

If you create a rectangle shape its initial angle is = 0º. Now, also this 0º is a property of this rectangle. Its angle was not transformed yet.

Correct.

 

5 hours ago, thomaso said:

The values in the Transform Panel show properties of layer objects numerically, they never show properties of the panel or of any tool.

Correct, which is yet another reason why "lock children" is not in that panel.

 

5 hours ago, thomaso said:

If the lock tells the tool how to behave – how can the lock be a property of the tool?

It easily can be.  Many tools, particularly large shop tools such as table saws, band saws and routers, have lock mechanisms of some sort to prevent them from operating if a child gains access to them or the like.  This is often in the form of a key which can be removed from the tool and stored separately.  If the key is not present the tool will not activate.

 

5 hours ago, thomaso said:

If a key tells a door not to open – is the lock a property of the key, or of the door?

If the key is talking directly to the door, then how is the lock even relevant?

 

5 hours ago, thomaso said:

If light makes a plant grow – is grow a property of light? If of light: who is growing?

Light doesn't make the plant grow.  It provides energy for the plant.  The plant grows on its own, fueled by the light (among other things).  Growth is an action, not a property.

[iuli]

When you gentlemen decide to develop the Philosophical Affinity Suite please sign me in, I’m buying!

Ok, I’ll show myself out now (look, a talking door!).

[thomaso]

20 hours ago, fde101 said:

This is often in the form of a key which can be removed from the tool and stored separately.  If the key is not present the tool will not activate.

This seems to confirm my view: key and tool are separate. The key activates the tool / deactivates the lock. Actually the lock in your machine samples behaves like the on|off switch of the tool: If the lock is active, the tool is switched off = does not work. Very different to MoveTool and "Lock children": if activated, the MoveTool still works, but the children don't react because they are locked. Only the children layers are locked, while the tool works as usual.

Compare a switch or fuse in electrical circuits. It can be part (property) of 1 device, e.g. 1 desktop light | or, as a wall switch, can lock various lights in a room | or lock the entire floor, building, street or city. Regardless of where its placed, the devices (tools) in its circuit always get locked entirely from working. Whereas the MoveTool still works if the children lock is activated. The lock makes the children ignore the MoveTool – while the tool keeps on going. (tool ≠ lock). For the children the MoveTool is off = for the MoveTool the children are off. But this lock doesn't have to be set by this tool, the process can work the same if "Lock Children" is placed in the "Document Setup…". Like the Transpareny Grid, which, though globally activated = unlocked, gets locally ~locked by & for objects.

20 hours ago, fde101 said:

If the key is talking directly to the door, then how is the lock even relevant?

To lock. Technically neither key nor door does lock, it's a lock which keeps a door locked, attached to the door. – When we say "I locked my car" or "This room is locked" we mentally & verbally confirm the lock as a part (= property) of their doors. Although we can use the key as tool to unlock, we even don't need it: door & lock can get opened with alternative methods.

20 hours ago, fde101 said:

On 3/18/2022 at 9:43 PM, thomaso said:

If light makes a plant grow – is grow a property of light? If of light: who is growing?

Light doesn't make the plant grow.  It provides energy for the plant.  The plant grows on its own, fueled by the light (among other things).  Growth is an action, not a property.

"Growth is an action, not a property." – Maybe I lack the proper English for "property", but for me an action can't just be a property, it has to be, of course: at least a property of 1 item performing the action. We all yearn for applications that do not have the property to crash (act crashing). A crash report tries to pinpoint a particular thread as the cause or owner of the property to crash, if we are lucky we detect e.g. a placed image resource as the property owner of causing the crash, while for us app users the crash act remains a property of the app.

Everything that happens needs at least 1 owner of the property that occurs to happen. If water is a property of clouds and water drops a property of weather, then the action of rain (= falling water) must have at least one owner of the property rain. So even the act of simply being is a property, just like the actions of breathing, growing, dying or locking. While dead, alive and locked are properties of the affected items (e.g. child layer), they are hardly properties of those items (e.g. MoveTool) which initially set this properties. It is the plant which growths, not the light. Though light is a condition to make a plant growing it hasn't to be the sun (tool). Since a plant (child layer) has the property of a limited max. size (locked | unlocked), the light (tool) can't influence their (child layer) property (lock) unlimited.

Back to the roots: currently the MoveTool has the property implemented to be allowed to display an UI item to switch "Lock Children" on / off, while child layers have the property of being locked / unlocked. The lock state of child layers is completely independent of the UI item that causes that state. So the lock is still not a property of the tool but of the affected child layers: A child layer does neither need the MoveTool to be locked (it can be set by any UI element) AND it does not need the MoveTool not to move, while the MoveTool has no way to move such locked child layers, regardless of who locked them. This independence distinguishes child-lock & tool from each other and distinguishes them from the chicken-&-egg problem and from a purely linguistic issue.

[Intuos5]

+1 I would also like to hotkey the "Lock Children" toggle.

And preferably, also control it with a modifier key as well.

[thomaso]

43 minutes ago, R C-R said:

How would feel about adding a button at the bottom of the Layers panel next to the "Edit All Layers" button to indicate the global status of this lock & of course to be able to turn it off & on?

Yes, either there, – or top right, next to the existing layer lock. To get the space for an additional icon in the top bar the text "Opacity" could get replaced by an icon + tooltip.

[Stepaan]

+1 to Lock children shortcut. Or even better a keyboard modifier? Are there any free modifier keys combinations?

[Ash]

Hi All,

Thanks for this suggestion. We have now added Space as a modifier for Lock Children which you can try now in the 2.4 beta which is available now. Hopefully it achieves what you were after! More info here:

 

[Stepaan]

Thank you. Works as desired on Windows 11.