Exstensions

[KingTaylor]

Hey, could we please get and extensions tap similar to Inkscape's. Not havings things like a wireframe sphere have been a real pain in the but, also the ability to generate a Voronoi diagram from paths would make creating polygonal backgrounds a lot easier and quicker. I really hope you add these things considering Inkscape (a free program) has them. 

PLEASE! 

[JET_Affinity]

Personally, I'd prefer a Javascript-based scripting implementation (with a thoroughly-documented object model). But now is probably not the time, since the program's functionality is still very much a work-in-progress.

JET

[Mithferion]

2 minutes ago, JET_Affinity said:

Personally, I'd prefer a Javascript-based scripting implementation (with a thoroughly-documented object model). But now is probably not the time, since the program's functionality is still very much a work-in-progress.

JET

As it was said in a interview, on PrintWeek:

• In the meantime, Serif plans to work on extensibility, to open up Affinity so third parties can write plugins and links, historically part of the appeal of Adobe’s and Quark’s success. “If everything goes well we may have that capability towards the end of next year, 12 months away,” says Hewson. “We will then be wanting to talk to people who might want to take advantage of that. There are very specific high end use cases for print.

The 12 months would meet their end by December of this year.

Also, as some Developers have stated here in the Forums, JavaScript is their language of choice.

Best regards!

[JET_Affinity]

Mithferion,

That quote sounds to me more like it's all about third-party commercial plug-ins, not about an end-user scripting implementation.

I don't get excited about plug-ins. I learned early-on in the 80s to avoid dependency upon third-party plug-ins marketed toward users like the plague (as opposed to those aimed at things like production; pagination tools, drivers for NC devices, etc).

Illustrator is the case-in-point. AI users spend a lot of money and time on third-party plug-ins just to add "missing" functionality, like dimension tools, or halftone effects, or better path manipulations. Such plug-ins are typically disproportionately expensive; often costing half-again the cost of the host program, or more. They chronically (and understandably) fall out of sync with the current version of the host program, sometimes lagging behind version changes by months. That is likely to worsen as most of the old-world software vendors have moved toward annual version changes (providing less and less in the way of substantive improvement per version) in attempts to smooth revenue flow.

User plug-ins are seldom as smoothly integrated as would be native features. CADTools, for example, much as many like it, practically constitutes a whole other interface when its active. That's not functional elegance.

To the user, third-party plug-ins are additional licenses and version updates to maintain. Their creators are usually comparatively small firms, which come and go.

Moreover, third-party feature add-ons from all these varied sources are written to interface with the host program, but are effectively oblivious to each other. So adding a collection of plug-ins to a drawing program's interface tends toward grab-bag clutter and sometimes even redundancy. For example, suppose instead of waiting for Affinity to gain its arrowheads feature, we bought a popular plug-in called Pointers4Affinity from a company called StartupA. Instead of waiting for Affinity to gain a dimensioning feature, we buy a plug-in called Rulers4Affinity from a company called StartupB. What's the likelihood of being able to use our arrowheads in conjunction with our dimensions?

That's why Illustrator's 3D Effect resides in its own modal dialog. It's just a plug-in based on a very limited functional subset of the defunct Adobe Dimensions application. Apart from its ability to import a Symbol from the current document's Symbols library as mapping art, it is essentially separate from the rest of the program. Each instance of it on the page is conceptually a "separate document" of that plug-in. It can, for example, turn a circle into a torus (by revolving the circle) OR it can turn a circle into a cylinder (by extruding the circle). But it can't make that torus orbit that cylinder within the same model space.

In short, I consider it potentially self-defeating folly for creatives (freelance illustrator and designers) to allow themselves to become habituated to (i.e., make their businesses mission-critically dependent upon) such add-ons. To my mind, the "plug-in architecture" concept, loudly marketed to end-users as the "next big thing" in the 90s, has been largely a failure.

A well-done scripting implementation is another thing entirely. It empowers the user to autonomously automate his repetitive routines far more powerfully than with just a macro feature (like Adobe's Actions) that merely records a sequence of (some of) the commands available in the standard UI. But moreover, as the user gets his feet wet, he finds he can essentially create his own vertical-need "features" that do exactly what he needs, by using variables, calculations, and conditional logic while accessing the actual objects, methods, and properties of the elements that lay beneath the standard user interface.

Scripting is not for everyone, because it assumes at least beginner level understanding of the language used. But those languages are openly, widely, and freely used standards accessible to any interested user. JavaScript, Python, VBA, AppleScript, etc. By "well-implemented" I mean:

• A thorough, well-organized, and reliably updated documentation of the program-specific object model (not of the scripting language itself; that's up to the user to obtain elsewhere).
• Inclusion in that object model access to at least the basic objects for UI alerts, modal windows, and non-modal palettes, so that the scripter can cleanly present the necessary script-specific user options when the script is run.
• Clear, simple, and practical examples of using each object.

Adobe has done a pretty good job of this; arguably too good by including not just Javascript, but also platform-specific languages (VBA and AppleScript), each of which requires its own documentation. Instead of platform-specific scripting languages, I'd frankly rather see a native program-specific scripting model like in FileMaker Pro. That has a full user-interface, excellent documentation, and being native, empowers the same script to work on any platform on which FileMaker runs, including FileMaker Server.

Inkscape, on the other hand, now sort of "favors" Python, but its documentation (being dependent upon volunteers) is weak and scattered. "Examples" in its case pretty much involves dissecting existing "Extensions" that are bundled with the program. That's not an easy path for scripting newcomers.

Also, bear this in mind regarding the best language to support: Adobe apps are scriptable in Javascript, not Python. Many users, like me, have cut their graphics scripting teeth on Javascript. It would be a relatively short transition for us to Javascript for Affinity. That consideration is compounded by the potential importance of embedding scripts in PDFs. Acrobat is still unavoidable in my workflow, and you can do wonderful things with Javascripted PDFs.

So if I had my heart's desire, Affinity would focus on developing an excellent (as described above) single-language (Javascript) solution to empower its users. That's cross-platform, open-source, full-featured, and has a long-established ubiquity in other environments, including the web.

I would think Affinity has this huge potential advantage: Adobe has to provide and maintain separate and different scripting implementations for each of its products, because they were developed (or acquired) separately. As I understand it, having been developed concurrently from the ground up, the three Affinity apps have the same underlying object model and code base. So I welcome correction if I'm wrong, but I suspect one thorough implementation and set of documentation could enable the Affinity scripting user to learn a single object model for the whole suite. Trust me, that would be a much less intimidating learning curve than gaining proficiency in scripting Illustrator, Photoshop, and InDesign.

JET

[fde101]

4 hours ago, JET_Affinity said:

That quote sounds to me more like it's all about third-party commercial plug-ins, not about an end-user scripting implementation.

Depending on how the API is written, a plugin could be used to implement a scripting language, meaning that multiple scripting languages could theoretically become available.  The reverse is not true.

[Mithferion]

23 hours ago, JET_Affinity said:

Mithferion,

That quote sounds to me more like it's all about third-party commercial plug-ins, not about an end-user scripting implementation.

Let me see if I can find relevant comments on Scripting capabilities for users, from Serif Staff members, but just by memory, the idea is that it will be accesible to anyone.

Best regards!

[Mithferion]

23 hours ago, JET_Affinity said:

By "well-implemented" I mean:

• A thorough, well-organized, and reliably updated documentation of the program-specific object model (not of the scripting language itself; that's up to the user to obtain elsewhere).
• Inclusion in that object model access to at least the basic objects for UI alerts, modal windows, and non-modal palettes, so that the scripter can cleanly present the necessary script-specific user options when the script is run.
• Clear, simple, and practical examples of using each object.

This would add a lot. I’m not a programmer myself, but JavaScript is in my personal list of future skills to develop.

Best regards!