Lorenz Kraft

@MEB: Thanks for your insights. There are very valid points that you pointed out. I had to rethink several of my opinions and came to one conclusion: I see one point different from a software developers view: - Opening your software (or file format) will not broaden the scoop (in the meaning of "bloated") of Affinity Designer/Photo/etc. The software will stay the same. Not bloated or anything, if done correctly, now a days a "standard" (see REST API). But as you mentioned, it would be the best idea to have a specific software for this purpose ... but actually what is the purpose? Purpose for a web developer? For a pre print engineer? The secretary that wants to print personalized invites based on Affinity Designer layout? In my opinion, this will not make anything better, because the scope to cover for this software is very broaden. So the best way is to have an API and a easy, if not already picked up language, like JS, Python etc. to fulfill your end result. With an API it will be possible to write plugins for specific needs. Actually, a plugin IS what you named "yet another Affinity application". Greets and thanks for all the inputs!

Jap, i think it depends on your point of view. From a "Graphic" Point of view, i don't see so many "typical use cases" and totally agree with a an extension as a "standalone" app, but from a web developers view, scripting makes so much sense in many points. I just digged out a video from a conference that shows many needs (and solutions) from a web developer perspective to work with PSDs: The general Affinity approach to use one format for all upcoming software (am i right here? thought i read it somewhere here in the forum) and the possible connection for a API (Software or Meta) is much groundbreaking, especially for automation (like "personalize a Layout that is done in Affinity Designer/Photo/???).

Hi all, @MEB: Are there any more informations about the support of Plugins that Affinity Photo will support? @All: Depending on the "depth" the API should provide, it should be possible to "Script" any Plugin. This also depends on your skill in the provides language and experience with it. As i see it, even a relativ simple API could give, for example web developer, many aspects about to get happy. Starting with many "automation processes" like: - extract "element -logo-" from all 3721 Affinity Documents in @2x Resolution - change the "element -website_url-" in 2367 Affinity Documents Going over to "mid size processes" like - Ask several questions and use this infos to fill in a address field - Ask some project details to use the right template afterwards Ending at "enterprise processes" - currently no simple example... There also might be a central repository for developers to add new plugins (also containing "Badge" System for developers/extensions), because i mainly hate it to look all over the internet to find some plugins that are no longer maintained and which give no hint if they work with the current version. No longer maintaing does not equal to be a bad extensions. Some things are as perfect (simple?) as it can be and there is nothing more to add (have a look at several VIM Plugins) I think a "npm" like repository or the way Adobe Brackets handles extensions seems almost perfect. Bye

Hi and thank you for your feedback. You are right with HTML and CSS, that for i a wrote "platform independent language" to not mix those different type of logic. Using those platform independent languages, i think, the software has a "low entry barrier" and makes room for more visions. Well, the drawbacks of possible slow software due to ugly programmed scripts should be addressed in first place. I think a software should be responsive (in the meaning of user interaction) to have fun with.

Hi all, i'm currently trying out new software and saw your promising new tool. I played around and noticed a missing killer feature: Extensibility! or to be more precise: a API for Extensions or/and API for your file format. API for your Software: Adobe has something that is called CEP (some examples: https://github.com/Adobe-CEP/Samples). Due to its current attraction, i would recommend JS,HTML,CSS as platform independent language for writing extensions. API for your file format: It would be even more cool if there would be an API for accessing meta data and "software actions" in your file format. "Software Actions" might be something like "Export as 2x PNG Image". This way, it would be possible to write extensions for Adobe Brackets, Atom or Sublime Editor to access (and extract/modify/delete/export) elements. I think this would take web development with your software (or file format) to unspeakable ease. If you have any more questions, please feel free to contact me. Bye