Wish: Lock position and Name/Nickname of canvas objects

Hi David,

I just did a search for "lock position" and a couple of threads popped up. I can see that this topic hasn't come up in a few years, but I thought I would revive the subject.

In those threads the feature of being able to lock a parameter or component on the canvas was mainly presented as a substitute for the now re-implemented Remote Control Panel. However I find that such functionality stretches beyond that. Perhaps it is a case of clumsiness combined with slight OCD, but I find myself constantly moving sliders, components and groups unintentionally. Then moving them back "where they should be" and adjusting/aligning them using Mr. Sparkle. Being able to lock them in place would therefore be great :)

Extending that, and perhaps a more critical feature, is the ability of locking the name of a slider, boolean toggle or parameter etc. I have started to build the user interface logic of my definitions by scripting the values of sliders/toggles based on actions performed by the user. A simple example of this is having a button which resets a list of sliders to a default value defined in the script. I realize that this option is also available using "Save State", however more complex relations require scripting. For instance, if a boolean toggle named "foo" is set to False a slider named "bar" is set to 42. Obviously such functionality is dependent on consistent naming, hence the ability of "locking" names/nicknames would be beneficial.

I'm not really sure that these features would be of much use outside the described scenarios, but if they are "easily" implementable I would certainly greatly appreciate them.

Best,

Anders

Ps. Really looking forward to seeing yourself and Daniel in Hamburg.

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on June 18, 2014 at 1:55pm

I forgot to highlight the suggestion made by Mark here, in which it is proposed that "position lock" could be implemented to work on a group level. This would be particularly useful if you are refactoring and have to unlock and move several objects (i.e. you would simple unlock the group and move that).

Permalink Reply by David Rutten on June 18, 2014 at 2:15pm

Is this locking just a UI option, or are there passwords involved?

Should the display of sliders/components that have (some) locked properties be different from unlocked ones?

David Rutten

david@mcneel.com

Permalink Reply by Anders Holden Deleuran on June 18, 2014 at 2:32pm

It is just a UI option accessible from the right-click menu on par with "Enabled", no passwords involved. Locking a group would lock all objects within the group.

I suppose some visual clue might be in order similar to "Enabled" and "Preview". On the other hand locking does not actually change behaviour. And if you can't move something it "is obviously" locked ;)

Permalink Reply by David Rutten on June 18, 2014 at 2:57pm

There are lots of properties which could be locked:
- name
- position
- existence (whether or not you can delete an object)
- value(s)
- slider range
- slider accuracy
- group outline type
- preview
- selection state
- and on and on

If you copy/paste a locked object, I think it should become unlocked. This means it's not just another property, but it has to behave differently in different situations.

I don't agree that "if you can't move something it's obviously locked". If the user doesn't know about locking, it would appear to be an obvious bug. Rhino displays locked objects differently, unless they are on a locked layer. This inconsistency has always annoyed me.

I think it's a good idea to have lockable properties, and I want to make sure that it's implemented in an extensible fashion, yet isn't confusing to new users. First step is always to figure out what features can be combined into one.

Permalink Reply by Anders Holden Deleuran on June 18, 2014 at 3:20pm

Ah sorry, the "obviously locked" was a poor attempt at stating that it wasn't in fact obvious, especially for new users as you point out.

I fully agree with your observations and hadn't even considered what would happen if you copy/pasted. Nor had I considered how deep the rabbit hole goes as far as how many properties could be lockable. I suppose there is a fine line between the flexibility of the canvas and a more fixed GUI such as the RCP. Either way, I'm glad to hear that you will consider "locking" as a potential feature. Me and my OCD :)

Edit: Generic properties that I would like to see lockable would be:

- Name
- Position
- Existence
- Size (for sliders and panels)

Permalink Reply by Brian Ringley on June 24, 2014 at 2:53pm

David, Anders,

I'd like to lock objects for the purpose of standard title blocks for the office, therefore this would strictly be a UI option, and strictly for the object's position property.

The display should absolutely be different, but I'd prefer icon-based display changes (a lock in the corner, possibly even an icon that does not appear until the user has reached a sufficiently close zoom level, like with Panel component formatting tools) rather than overall graphic display changes (e.g. the graying-out of locked geometry in Rhino). The reason for this is that the sketch objects and group objects are stylized and colored very deliberately for the title blocks and we wouldn't want this to change based on the state of the locked position property.

Alternatively, a subtle interior drop shadow might work as it could create the sense that the component has been "stamped" into the canvas and this would likely be perceived as immovable.

The aforementioned objects (sketch objects and group objects) are the only objects for which I currently wish to have locked positions. Because individual component positions within groups are children to the position of the group object itself, there'd be no need to lock the former provided I've locked the latter.

I agree that a copy/pasted object should always default to unlocked - you would almost always be pasting a locked object in order to re-position it, regardless of whether you eventually intend to lock its new position.

Thank you for your time!

Brian

Permalink Reply by Andrew B. Reitz on April 4, 2015 at 6:51pm

Hi David.

When you say "there are lots of properties which could be locked:" are you saying that there IS currently a way to lock, for instance the position? Or there will be? If so, how could this be accomplished with RhinoScript / grasshopper in the SDK?

Thank you.

Permalink Reply by nikos tzar on June 25, 2014 at 7:23am

hi all,

maybe i'm missing something but I don't understand why the display of a locked object should be different at all times (and also how this would be possible with various types of locked properties).

I believe the ideal would be a locker icon popping out whenever the user tries to change a locked property (that is: tries to move a component that has locked position - rename a component that has locked name - resize a component that has locked size etc...).

I don't know though if this could create problems in moving multiple objects.

thank you for your time,

nikos

Permalink Reply by David Rutten on June 25, 2014 at 8:45am

I'd imagine every property that is in a locked state needs to signal this to the user. If the name is locked, then instead of an editable textbox in the popup menu you'll see a locked icon. The Preview and Enabled states will be greyed out and have locked icons. The only problematic property is position+size, as it that one is accessible without a menu. Perhaps there should be a small anchor/lock icon when the mouse is near, perhaps only if you try and drag it, perhaps all the time, perhaps all the time but only at >100% zoom... I really don't know what works best yet.

David Rutten

david@mcneel.com

Permalink Reply by Miguel Villegas on October 6, 2016 at 3:03am

Hi, David et al.
Any news on this front?

Permalink Reply by David Rutten on October 6, 2016 at 6:45am

No, but it won't happen for GH1, it's been in feature lockdown for years. GH2 will in all likelihood have some locking mechanisms.

Permalink Reply by Martin Smith on May 23, 2019 at 8:33am

Hi David,

Any news on the rollout of the locking function? I'm surprised this feature hasn't been brought up more. Thank you for considering implementing it into a future GH

RSS