A preview of Adobe Extension Builder 3, a new developer tool that supports creating HTML5-based extensions, was launched in June at Adobe Labs. You can download it for free from here: http://labs.adobe.com/technologies/extensionbuilder3/
Starting in the middle of 2014 we will begin removing Flash-based extension support in Creative Cloud products, starting with Photoshop CC. We encourage all developers to start planning and migrating to the new extensibility framework based on HTML5.
Check out these videos to see how to build and debug HTML5 Extensions.
I have read:
We have an automation plug-in (C++, Photoshop CS1-6 and CC) that basically exports layered Photoshop file into separate images and makes some text files associated with export process. Basically instead of Save or Save As our users call action that calls our plug-in.
That is why we want to move functionality to panel - to make exporting one click task instead of File-Automate - Dialog ... or recording an action). So we have planned extensive UI facelift (for CC version only). We can move all elements of GUI to panel.
We have considered following path:
Flash builder - GUI
Configurator + Flash Builder - GUI (configurator do not have all things that we need)
Java script controlled from GUI would be used to pass parameters from collected from to plug-in using scripting parameters (plug-in is script aware).
It is good that I have seen your post since if I have understood well, it is advisable to move to HTML 5.
Now the questions that I have:
1) We need almost all Dialog GUI elements at our disposal (radio buttons, directory choosers for saving , text entry fields etc... ), is that possible? (we had a problem in choosing directory for save using java script).
2) Can we call automation plug-in using HTML 5
3) Can we read from registry (Photoshop registry to be clear) parameters that automation plug-in writes, and write to registry parameters that plugin can read using HTML 5/Java Script ? (Here is the example C++ routine that writes to registry):
SPErr error = kSPNoError;
PIActionDescriptor descriptor = NULL;
Boolean tempBool = false;
DescriptorEnumID bgmode, lymode, fmode;
if (sPSActionDescriptor != NULL )
error = sPSActionDescriptor->Make(&descriptor);
error = sPSActionDescriptor->PutString(descriptor,keySaveDIR,text);
error = sPSActionDescriptor->PutEnumerated(descriptor,keyBgExt,typeFileExtens ion,bgmode);
error = sPSActionDescriptor->PutEnumerated(descriptor,keyLyExt,typeFileExtens ion,lymode);
if (descriptor != NULL) sPSActionDescriptor->Free(descriptor);
} // end WriteToRegistry
Similar C++ routine reads from registry.
Java script that calls our plug-in (example that we used to run plugin from configuration menu ) looks like this.
function fSSEX64 ()
var idExportSSsixfour = stringIDToTypeID( "ExportSS64" );
var descAmssex = new ActionDescriptor();
// OPTION GROUPS - ENUMERATORS- BG, CLIP EXTENSIONS AND SAVE MODE
var enumJPG = charIDToTypeID( "fJPG" ); //#define fileJPG 'fJPG'
var enumPNG = charIDToTypeID( "fPNG" ); //#define filePNG 'fPNG'
var enumBMP = charIDToTypeID( "fBMP" ); //#define fileBMP 'fBMP'
var enumTIF = charIDToTypeID( "fJPG" ); //#define fileTIF 'fTIF'
var enumOver = charIDToTypeID( "sOVR" ); //#define saveOVER 'sOVR'
var enumAppend = charIDToTypeID( "sAPP" ); //#define saveAPPEND 'sAPP'
var enumNew = charIDToTypeID( "sNEW" ); //#define saveNEW 'sNEW'
var ssexTypeImgExtension = charIDToTypeID( "tFEX" ); //#define typeFileExtension 'tFEX'
var ssexTypeSaveMode = charIDToTypeID( "tSMD" ); //#define typeSaveMode 'tSMD'
var ssexParamBgExtension = charIDToTypeID( "bgEX" ); //#define keyBgExt 'bgEX'
var ssexParamLyExtension = charIDToTypeID( "lyEX" ); //#define keyLyExt 'lyEX'
var ssexParamSaveMode = charIDToTypeID( "mSMD" ); //#define keySaveMode 'mSMD'
//STRINGS SCRIPT DIR, CLIP DIR, LABELE
var ssexParamSavePath = charIDToTypeID( "mSPT" ); //#define keySavePath 'mSPT'
var ssexParamSaveDir = charIDToTypeID( "mSDR" ); //#define keySaveDIR 'mSDR'
var ssexParamPageLabele = charIDToTypeID( "AMLA" ); //#define keyLabele 'AMLA'
// INTEGERS - DEFAULT DURATION
var ssexParamIntDefDuration = charIDToTypeID( "iDDU" ); //#define keyDefDur 'iDDU'
// BOOLEANS - CHECK BOXES
var ssexParamUniqueNames = charIDToTypeID( "mUNM" ); //#define keyUniqueNames 'mUNM'
var ssexParamSetTreatment = charIDToTypeID( "aSET" ); //#define keySetTreatment 'aSET'
var ssexParamUseAbsPath = charIDToTypeID( "mABP" ); //#define keyAbsolutePath 'mABP'
descAmssex.putEnumerated( ssexParamBgExtension, ssexTypeImgExtension, enumJPG );
descAmssex.putEnumerated( ssexParamLyExtension, ssexTypeImgExtension, enumPNG );
descAmssex.putEnumerated( ssexParamSaveMode, ssexTypeSaveMode, enumOver );
descAmssex.putString( ssexParamSavePath, """C:\\00-ex\\uw.sca """ );
descAmssex.putString( ssexParamSaveDir, """Use Default""" );
descAmssex.putString( ssexParamPageLabele, """Use Default""" );
descAmssex.putInteger( ssexParamIntDefDuration, 0 );
descAmssex.putBoolean( ssexParamUniqueNames, true );
descAmssex.putBoolean( ssexParamSetTreatment, true );
descAmssex.putBoolean( ssexParamUseAbsPath, false );
executeAction( idExportSSsixfour, descAmssex, DialogModes.ALL );// or other dilaog modes
Very sorry for the long post, but any help or suggestion will be much appreciated.
Using Configurator/Flash Builder/Extension Builder (earlier version), showed to be very confusing combo.
Thanks in advance to all members of the forum for any kind of input.
You do realize that the goals and interests of Adobe and those of the developer community are somewhat diametrical. Adobe wants to sell its latest products or recently to get people to sign up for creative cloud. The developer community wants to offer their products to a broad audience. That is we do care to support at least a couple of software versions into the past. Supporting only CC would really narrow our group of potential customers especially with the group existing that despise of the "software as a service" route of recent days. Now adding new features to PS CC is great, please keep doing that. HTML5 panels seem like an interesting idea, too.
But removing features from PS CC is a bad idea! In that you do two things. You force developers to develop two panel versions – one Flex based for CS4 through CS6 and one HTML5 based for the future PS CC. By removing support for the flash based panels you have been propagating for the last years you bring your customers into a predicament, too. They can’t use stuff they bought and that uses panels. They will not necessarily get free upgrades to any such products nor will such updates even necessarily be available. In the old perpetual license world that would have been no problem. You could keep you PS CSx (where “x” is any version) installed paralelly and be happy with it.
Today - if you don’t also own CSx - can you keep multiple versions of PS CC installed? I think not. Therefore removing functionality from PS CC that once was in PS CC is a really bad idea in my opinion. Especially since the Flash stuff is Adobe’s own technology it seems kind of nonsensical to kill its support.
One of my concerns over the removal of Flash based panels is whether this is going to affect the current file info panels. In particular if people have constructed custom file info panel, will these still work? Also if there are ExtendScript UIs that use a Flash interface, will those stop working as well?
Agree. Removal will be very distructive. Hopefully this will be reconsidered! I know that all the plugins of Fl that I use on websites will create a major work load for me in revamping and trying to figure out what will remain for any given time before that also changes. Not good thoughts!