Causes errors on the ‘text_layer1.textItem.color = text_color’ line…
Traceback (most recent call last):
File “/Volumes/Droid/GREM/Production/Shotgun/PipelineConfigurations/Toolkit/install/app_store/tk-multi-pythonconsole/v1.1.2/python/app/input_widget.py”, line 190, in execute
exec(python_code, globals(), self._locals)
File “python input”, line 9, in
File “/Volumes/Droid/GREM/Production/Shotgun/PipelineConfigurations/Toolkit/install/app_store/tk-framework-adobe/v1.0.4/python/tk_framework_adobe/rpc/proxy.py”, line 281, in setattr
self._communicator.rpc_set(self, name, value)
File “/Volumes/Droid/GREM/Production/Shotgun/PipelineConfigurations/Toolkit/install/app_store/tk-framework-adobe/v1.0.4/python/tk_framework_adobe/rpc/communicator.py”, line 487, in rpc_set
proxy_object,
AttributeError: Unable to set property color to value on object
This is a weird one, but I have a workaround for you that will work. The short answer is that it also fails when running the equivalent of your Python code directly from ExtendScript/Javascript, even though I agree with you that Adobe’s docs imply it should work. In addition to that, what I could get to work using JS directly behaves strangely when run through our Python RPC API. I’m not sure what’s going on there, but the gist of it is that each time the layer.textItem.color.rgb property is referenced, a different object instance is being returned. I’m guessing it has something to do with the fact that we detach and cache the object under the hood and refer back to it later, but I’ve not seen this particular behavior elsewhere in the ExtendScript API.
The workaround is the following:
adobe = engine.adobe
ll = adobe.app.activeDocument.artLayers.add()
ll.kind = adobe.LayerKind.TEXT
ll.textItem.kind = adobe.TextType.PARAGRAPHTEXT
ll.textItem.contents = "test"
# Since you just created the layer, it will be the active layer.
# Call into it directly via javascript using rpc_eval and you'll
# be able to set red, green, and blue on the RGBColor object
# that's already assigned to textItem.color.rgb.
adobe.rpc_eval('app.activeDocument.activeLayer.textItem.color.rgb.red = 255')
It’s not as pretty as doing it all in Python syntax, but hopefully it’ll get the job done for you.
I have seen a lot of weird behavior when trying to replicate JS ExtendScript stuff, particularly in Premiere. Seems like a lot of times I always have to call things from the root rather than re-use a handle. Always starting with ‘app.’.
I have also had instances where I could use something like…
text_color.rgb[‘red’]
but not…
text_color.rgb.red
I have a couple of other dead-end issues that I will try with the rpc_eval() method.
It’s worth a shot in other places, yeah. I was hoping I could figure it out quickly and at least tell you we’d have a fix in sometime soon, but I’m a bit stumped at the moment. That being said, I’ll think about it some more, and since I’ll likely be in that code again within the next few weeks I might take a second crack at debugging it then.
But, what I am really excited about is that this also helped to solve an issue with my Premiere Engine!
Here is what works in ExtendScript…
var path = “/Volumes/Production/post/jobs/GREM/250/source/Storyboard/SB_V01_20190326/GREM250_TST_0250_Sb_V01.mov”;
var results = app.project.importFiles([path]);
Here is what I have been trying in the Python Console…
I have no goo answers here except that it always seems to behave differently from instance to instance.
Sometime only one.two.three would work, other times I had to use one.two[‘three’].
There never really seemed to be any sense to it. and it was just a ton of trial and error.
It seems any operation longer than about 4-5 minutes will crash the engine, actually the adobe framework. This goes for Photoshop, Premiere, AfterEffects and Illustrator. There are soo many cool things that COULD be done in Premiere but between the crashes on long operations (goodbye exporting timelines as QTs) and the slow-as-hell communication back and forth between Python and the App.
I have a some neat stuff developed for Premiere but it’s too slow to be really useful. Imagine being able to query Shotgun for the Status of Versions in the sequence timeline or Publishing cut information to SHogun without exporting an EDL to Import Cut!
The Premiere ESTK is horrible too. Decent docs, horribly limited API. For example, there is no way to get what is selected on the timeline. You have to query EVERYTHING and loop though everything and check to see if its selected. Way too many operations to do simple things Editors do. It can take 20+ minutes just to crawl through a heavy timeline looking for a selection to perform an operation, then it still has to do the work. I honestly hope your having a better user experience that I had. Most of these thing (except the crashing) are less of an issue in Photoshop where the operations are less intense and include far fewer files.
