Currently I don’t think Actions are visually represented in the Overview (@marcus?). Would be an interesting feature to add the actions icons to the plugin when appropriate.
Mm, that’s right.
Have a look at the announcement thread for examples.
They’re in the right-click menu, you can assign custom icons to each item as well.
But you can’t see whether a plugin has actions associated, without right-clicking on it. If you added the icons of an action to the plugin visually, similar to how the wrench looks now, the user would know whether there are actions on a plugin without knowing in advanced or right-clicking.
I’d imagine that the user still needs to right-click to execute the action, but they can see in the overview that a certain action is present for a plugin.
I was planning on adding permanent/default actions to all items, such as opening the folder of a particular plug-in and such.
I was specifically looking for a way to have an “icon” be added to the plug-in in the overview just like the Repair icon did before. So that one doesn’t need to right click?
Could the Actions have something like that?
#pseudocode
class MyAction(Action):
icon_in_overview = True
...
No. Just, no.
Haha, well that clears that up. 
Will have a go with the actions as is and let you know if I run into problems.
Hehe, yeah. I’ll sound like a broken record, but it doesn’t have enough to do with (my view of) publishing. What you guys need are other tools that repairs and modifies things.
I still think that having icons about available actions would be good, to indicate to the user that a plugin has actions. The icons would be purely visual, without any button functionality. The below illustrates my view (sorry about the poor photoshop skills on the icons)
The reasoning behind this, is that we have several validators that don’t have a repair action. Without right-clicking on all the failed validators, the users wouldn’t know which they can potentially fix automatic. Having an icon they can look out for , for fixing problem with an action makes it super-easy for the user to know what to do.
1 Like
I’m absolutely behind this too. We haven’t switched to actions for this very reason. I don’t want artist to be right clicking on everything just to see if they can do something with it. Right click to actually launch action is fine. But without indication it’s there, we don’t have much use for it right now.
If there is one feature that artists love, then it’s the ability to repair. I know you don’t like it and don’t see it as part of publishing, In this occasion though I feel it’s a matter of opinion.
1 Like
I do feel that just having every icon depicted there might hold people back from putting clarifying icons in the menu to hold the overview from cluttering. Especially if there are “default actions” (I think @marcus mentioned thinking about that) that have icons.
Takes me back to thinking having a way to enable an icon to be shown in the overview is the way to go, as mentioned here.
For me, even a single icon depicted that there are some action on the plugin would be enough.
Repairing is useful, I’m not arguing that. Every studio should have the means to repair. Just not with Pyblish.
The tool you guys are looking for is one you need, but it isn’t Pyblish. Pyblish does validation and output, that’s it. Keep it simple, small responsibilities.
To be honest, I’m surprised neither of you have gone ahead and developed a repair app. You could even re-use concepts of instances and families to associate them with particular assets, like you do in publishing. It’s so close and, dare I say, easy. That app would have all the room in the world for all sorts of features related to repair, because a single one-off button is only the beginning of what’s possible in this area, and I’d hate to see Pyblish keeping you from reaching this potential.
The thing there is that you’d validate… and find out you’d need to repair. It’s so close to each other, so connected. It’s even so “close” that I feel Validators should be so descriptive that the artist instantly knows or learns how he should fix (repair) the problem at hand.
I think removing repair() is a totally fine decision because you wouldn’t want it as recommended behavior, which is a fine preference. But I don’t see why the interface shouldn’t support people to customize it to their own needs. The fact that there are 3 people here mentioning now that repairs have been beneficial to them (and their team) makes me wonder whether it shouldn’t just be this way… it’s convenient, and the validation is still there to ensure everything is correct.
It’s a discussion that has come up again and again and I’m not sure if I can personally bring more arguments to the table, or even whether it’s worth it to try.
About that, I feel that Actions give exactly that wiggle room to be even more specific regarding helping an artist to solve a problem; whether it’s repairs or something else. Like @mkolar said… if it’s just visible that a plug-in “has a feature” the artist learns (and knows!) that there might be more to it. E.g. could help him/her to select/highlight the problematic objects in a scene.
1 Like
The workflow is great, I’m not arguing there either. I’m saying you can have both, and more.
Trust me, once you have the repair app, you will not look back. Here, let me get things started for you.
Just wanted to get this clear. You suggest that we have a separate framework for repairing?
Separate everything, that’s right.
It can resemble Pyblish in every way, it just can’t be Pyblish.
Sorry about this, but this is not a rant or a go. Just arguing my point😀
I don’t understand the standpoint of not having repairing and validation together in the same framework.
This is similar to speak two languages. Describing a problem in one language and the solution in another. It’s definitely possible to do, but you risk loosing details in the translation.
As mentioned actions are already in place to accommodate for this, all we are arguing is that we introduce a visual aid for the users to find the actions.
1 Like
Maybe let’s step away from the repair for a bit a say it another way, once again.
Actions in general need a visual clue in the UI to let user know, they are available on the given plugin. As simple as that. If people are not told they can do something extra with the plugin, they won’t find out themselves. Expecting everyone to remember which plugins do and which don’t have actions is unrealistic.
Say I add action to plugin that didn’t have any before, which sends information and log to support, and which they can run if it fails. They will never figure that out if I don’t explicitly tell them.
This could really be as simple as bolder checkbox, or whatever to tell them ‘this plugins has something’ extra
1 Like