RFE: Make default expression of all new COMPs' Global OP Shortcut be be `me.name`

Does anyone else think it would be handy if the default expression for Global Shortcute of all new COMPs was pre-filled to be me.name? That way, as soon as you switch to expression mode, it’ll save you those keystrokes. I may be presumptuous as to how many people just use me.name for 99% of all global op shortcuts…

But isn’t it good practice to use all caps for global op shortcuts just to make them more distinctive and maybe pause and think carefully of the right name to use first?

Sure, I’m not suggesting to make the default parameter mode an expression, I’m just suggesting that if you change it to expression mode, it be pre-populated with me.name.

Am I presumptuous in assuming that 99% of all times expression mode is used in Global OP Shortcut parameter, it’s to have it be me.name?

Hey @matijaerceg,

one big benefit of (global) OP Shortcuts is that they don’t loose validity when the operator is moved or renamed. A default expression, while perhaps useful in some circumstances, has in my opinion therefor more drawbacks than benefits.

cheers
Markus

5 Likes

Indeed you are. In general, Global OP-Shortcuts should be used sparingly, if at all. And the moment you let an expression decide the name of the shortcut, you make the Op shortcut implicit.
From the outside (without looking at the params themself), it is not possible to see if a component has the globalOP-Shortcut. This will lead to issues when you just rename it to only later find out that you broke some important links.

3 Likes

haha :sweat_smile::sweat_smile::sweat_smile:

I use them a lot for comps that I know I will never rename. How many is too many?

I use them with OPs that there will only ever ever ever be one of in my composition, that i need to be able to access from lots of places, but I don’t think there should be a default here. if it isn’t an expression, copying them becomes a drag as it will duplicate and bark at you. We’re usually in lockstep with our UX concerns, but I’mma have to disagree this time

1 Like

It totaly depends on how you set up your project. I personaly like to make my projects as modular as possible.
One reason is that it is easy to work with others when components are seperated and saved as their own toxes.
Second reason is reusability. Creating components/modules that are only concerned with themself or get data fed by custom-parameters (top to bottom dataflow)/Inputs, makes it easier to reuse them in another project, saving alot of time. Same goes for more complex modules. For them I like to make use if iOPs and a central storage-component.

You say you know not to rename them. Do you also know this in a year? Do other people maintaining your project later on, coming on board, know this?
Sure, you can mark them in a meaningfull way, add a comment or annotation, (you might wanna do that anyway), but your timesaving is gone at that point.

2 Likes

Have to agree with the sentiment of using op shortcuts as sparingly as possible. It’s not op shortcuts are bad, it’s that there are actually better features in Touch to use, that will future proof your networks and lend more towards modularity and such. When you use those other features (parent shortcuts, internal params, etc) you’ll just naturally find yourself using op shortcuts more sparingly.

Sometimes it is necessary to reach out or in to a comp, using parent shortcuts forces you to think about passing data down into comps, and up out of comps a bit more explicitly as crossing some sort of boundary. Like through custom parameters, methods, storage, etc.

Also, as you build modules, you might start with something you think will never need to be replicated and get it working with op shortcuts, but later down the road you’ll find yourself wanting to copy or replicate it as instances of a template, then op shortcuts fall apart in another big way.

2 Likes