Search This Blog

Wednesday, 18 December 2019

Developing User Interfaces for Adobe Products


Choices when developing extensions and plug-ins for Adobe Creative Cloud and Document Cloud products

Most of Adobes Products has either come from other companies that have merged with Adobe Systems or have been in development for a considerable length of time. There is more than one way of creating extensions for most of Adobes products and especially the variation in developing graphical user interfaces. 

Adobe Illustrator, for example requires the use of HTML and JavaScript for its user interfaces. Adobe Acrobat supports native user interfaces on both Windows and Mac platforms although until recent versions that used to have its own user interface technology called ADM (Adobe Dialog Manager). The same technology was also used in Adobe Illustrator, however over the last few versions of the products this technology has been removed. For Adobe Acrobat there is an example plug-in using wxWidgets (https://www.wxwidgets.org/) an open source library which can be used across both Windows and Mac platforms but unfortunately this just means having to educate developers on yet another user interface technology, Adobe Indesign probably provides most options in supporting its own resource format and also HTML5.

Extensions for a lot of Adobes Creative Cloud products can also is be supplied as hybrid extensions and plug-ins using HTML JavaScript and also native plug-ins within the same package and product. This array of different technologies has not been made any easier by the fact that over the last years Adobe has created technologies and then consigned them to history. At one point the most of  the Creative Suite (precursor to the Creative Cloud) products supported user interfaces based on Flash and then that was discontinued in preference to using HTML 5, CSS 3 and JavaScript and is known as the Adobe common extensibility platform (CEP). Adobe Acrobat, a part of both the Document Cloud and the Creative Cloud follows its own development path in not using this technology.

Location of Adobe's current software developer kits and and CEP

Adobes SDKs (software development kits) are available from various links, but the most up-to-date set are available from Adobe.io for the latest iterations of Adobe products.

Beyond the GUI

Of course is a lot more to a plug-in or extension product then the user interface but generally this is the main element aiding or constraining cross-platform software development and of course the main part of a product that the user interacts with. The Adobe CEP interface is a big move to try and remove these constraints and to try and provide a consistent GUI across multiple products. Unfortunately one of our main development platforms is still Adobe Acrobat and this technology has not yet been adapted for this product.

CEP is advertised as a platform for those not wanting to use C++. For many products this is certainly the case that there are definitely constraints where a decision has to made if enough of the developer interface has been exposed to produce the product that is required. This will vary from product to product. However for interaction, speed, multi-threading and extensive task handling using the software developer kits natively is often the only option. An example of this is our integration of SMART boards and Adobe Illustrator where the CEP technology just wasn't sufficient. However CEP does have support for Node.js as this will bring in an extensive number of JavaScript libraries. However most of these applications are client based and so this is generally only useful in a client server type environment and the plug-in interfaces are nearly all C++ for which there is also a very extensive (probably more extensive) set of libraries that can be used.

Contact:

Michael Peters
mpeters@mapsoft.com
https://www.linkedin.com/in/mpmapsoft/
http://www.mapsoft.com

No comments:

Post a comment