Is it possible to disable functions when a group selection is of a certain type?
For example: I want to allow in a Digital asset to eighter select a primitive group or a point group. Depending on the type of group selected it should hide some of the parameters.
I can do this with a toggle, but it would be cleaner if it could go all automatic.
Cheers
Kim
A computer is almost human - except that it does not blame its mistakes on another computer.
arctor it would be cool to control the ‘invisible’ toggle on the type properties page…
From a UI standpoint, that is a horrible (yet cool!) idea. Why? Because then you have no idea that a parameter even exists. If it's greyed out, at least you know that there's something there that's valid in some cases (now you just have to figure out when).
arctor it would be cool to control the ‘invisible’ toggle on the type properties page…
From a UI standpoint, that is a horrible (yet cool!) idea. Why? Because then you have no idea that a parameter even exists.
I think it depends on what you want to achieve. I this case I'm building an otl that allows a point and a primitive. When things are greyed out automatically because of the grouptype makes it a bit smoother in the workflow.
Ideally I think you should be able to creat gui's like they have in modo. You can have a popup giving you a warning. That, for example, because of the grouptype some functionalities are unavailable. And if you don't want to get interruped any longer the user can click “do not show this message in the future”. Like this it is easy to learn the behavior, yet it will not stall the fluidness of working.
A computer is almost human - except that it does not blame its mistakes on another computer.
arctor it would be cool to control the ‘invisible’ toggle on the type properties page…
From a UI standpoint, that is a horrible (yet cool!) idea. Why? Because then you have no idea that a parameter even exists. If it's greyed out, at least you know that there's something there that's valid in some cases (now you just have to figure out when).
I agree the kinds of things I was thinking of would be - for eg: imagine you have a custom camera OTL in order to cram it full of presets etc you'd end up with giant menus etc… what if, on creating the instance, only the relevant parameters were visible, like the camera resolutions for JOB_A would appear in the resolution menu, but not the resolutions for JOB_B.
kgoossens I this case I'm building an otl that allows a point and a primitive. When things are greyed out automatically because of the grouptype makes it a bit smoother in the workflow.
OK, take that to the next step: you need to opparm something, and you keep opparming the parameter, and “nothing happens.” Why? Because you're accidentally opparming the invisible parameter.
It would be much better to have a single parameter that can handle both: be a point group in one case, or a prim group in another.
So I implemented something that might be similar to what you guys had in mind. It starts with a menu option (“simple” and “auto” in my case). Below it are two folder tabs, one called simple, one called auto. I set the folders to be in ‘menu’ style rather than the regular ‘tab’ style. Furthermore, in the callback of the simple/auto menu, I put in a callback to opparm the std_switcher# to the correct folder, and just for safety, put disablewhen's into both the auto and simple items (all the auto items are disabled when {menu “simple”} and vice-versa. So this makes for a nicely reduced visual – only the appropriate menu is seen (yes, you can go to the other one, but everything is greyed out).
