@rmawatson For some reasons some photoshop objects couldn't be created using win32com api, and comtypes could do that. I also couldn't create any of the objects to access plugins such as ActionReference, ActionDescriptor objects with win32com, so I used comtypes for that. Selection rects didnt' work either with win32com.. Also win32com didn't want to handle the string or char (4 letters) identifiers either so I had to use comtypes again.. didn't really like mixing these two modules.
@rmawatson Yeah I agree which is also the reason we used COM to drive our photoshop pipeline. This custom interpreter and custom bindings was just an experimental project I dedicated about 1-2 days and then left :)
"win32com AND comtypes to access plugins" - I never had to use comtypes aswell as win32com to achieve what I wanted, Im interested to know what problems you had with win32com alone ?
Very nice. I think an interpreter on its own running inside photoshop will provide very little (if anything) extra than is already provided by just running python itself in its own process, as COM is designed to interop between processes anyway. Our problem came when we wanted a bit of syncronicity in the design with event handling, this can only be done inside the photoshops process...
Yeah I know about win32com and comtypes for running photoshop.
Our CS3 solution used win32com AND comtypes to access plugins. The need to use both of these modules for ActionReference, ActionDescriptor objects was just bad..
I have moved our studio into CS5 now, creating ui / panels and stuff through the photoshop configurator. Works lovely, while calling our custom dds exporter plugin through javascript :) I don't see a need for python anymore to drive ps
We have done the same thing with some menuing support and callbacks for all core photoshop events and some additonal ones. The intepreter was fairly easy, but hooking up so you can intercept window and ps events took a bit more messing around.
The was reason to embed vs running python in its own process. You realise the COM scripting api is fully useable outside of photoshop using the win32com package and a regular python interpreter?
Hey lonewolf! Is this truely embeded or just overlaid? We are trying to find a good solution to make it fire up at launch time to inject our session tracking object(s).
I am assume a hard requirement is that the DLL/EXE also live with/next to the photoshop app iteself?
@rmawatson For some reasons some photoshop objects couldn't be created using win32com api, and comtypes could do that. I also couldn't create any of the objects to access plugins such as ActionReference, ActionDescriptor objects with win32com, so I used comtypes for that. Selection rects didnt' work either with win32com.. Also win32com didn't want to handle the string or char (4 letters) identifiers either so I had to use comtypes again.. didn't really like mixing these two modules.
Endureil 8 months ago
@rmawatson Yeah I agree which is also the reason we used COM to drive our photoshop pipeline. This custom interpreter and custom bindings was just an experimental project I dedicated about 1-2 days and then left :)
Endureil 8 months ago
@Endureil
"win32com AND comtypes to access plugins" - I never had to use comtypes aswell as win32com to achieve what I wanted, Im interested to know what problems you had with win32com alone ?
rmawatson 8 months ago
@Endureil
Very nice. I think an interpreter on its own running inside photoshop will provide very little (if anything) extra than is already provided by just running python itself in its own process, as COM is designed to interop between processes anyway. Our problem came when we wanted a bit of syncronicity in the design with event handling, this can only be done inside the photoshops process...
Nice work!
rmawatson 8 months ago
@rmawatson Yeah I've seen it :)
Yeah I know about win32com and comtypes for running photoshop.
Our CS3 solution used win32com AND comtypes to access plugins. The need to use both of these modules for ActionReference, ActionDescriptor objects was just bad..
I have moved our studio into CS5 now, creating ui / panels and stuff through the photoshop configurator. Works lovely, while calling our custom dds exporter plugin through javascript :) I don't see a need for python anymore to drive ps
Endureil 8 months ago
@Joviex It's truly embedded. You can go either way with the DLL being alive or not, latter clears python memory. I keep it alive.
Endureil 8 months ago
Search embedded python interpreter over at tech-artists . org
rmawatson 8 months ago
We have done the same thing with some menuing support and callbacks for all core photoshop events and some additonal ones. The intepreter was fairly easy, but hooking up so you can intercept window and ps events took a bit more messing around.
The was reason to embed vs running python in its own process. You realise the COM scripting api is fully useable outside of photoshop using the win32com package and a regular python interpreter?
rmawatson 8 months ago
Hey lonewolf! Is this truely embeded or just overlaid? We are trying to find a good solution to make it fire up at launch time to inject our session tracking object(s).
I am assume a hard requirement is that the DLL/EXE also live with/next to the photoshop app iteself?
Great tech. Cheers.
Joviex 8 months ago