Jon W
-
Posts
125 -
Joined
-
Last visited
Posts posted by Jon W
-
-
On 9/16/2023 at 12:04 AM, kimtorch said:
[...] it would be nice if we could have any sort of update on any progress being made.
I'm happy to report that SDK development is progressing well. We are steadily working towards exposing enough app functionality to make useful plugins, but there's still quite a lot to do before we can consider even a "technology preview" release.
-
Thanks everyone for all your suggestions - please keep them coming! They are all useful.
Initially, we'll be concentrating on exposing existing functionality - primarily, manipulation of documents and their contents.
Then later we will be able to move on to some of the "new feature" things that have been suggested: custom tools / shapes / brush engines / personas etc.
-
On 6/5/2023 at 4:46 PM, rui_mac said:
This is just a very simple example that I coded now in Cinema 4D. The script is attached to the top object, called "Null". This would be the equivalent of a layer or another object in Affinity. Then, no matter how many objects are set as children of the top object, the script always distributes them evenly between the position of the first and last child. As you all can see in the movie, I can add as many objects I want, and they will always distribute evenly. And it is fully dynamic.
Thanks for the explanation. Whilst dynamic layout is certainly an interesting idea, it's somewhat outside the scope of scripting itself - it would have to be considered as a completely new feature. Although we have no plans to allow general scripts to be embedded in documents (primarily due to security issues), if we were to add such a "dynamic layout" feature then I imagine we would use embedded scripts (with limited, layout-specific capabilities).
-
11 hours ago, CM0 said:
I recently made a post in this thread about some scripting capabilities that would be ideal for my use cases. Essentially a live scripting layer to combine the capabilities of procedural textures and equations etc. Detail in link.
https://forum.affinity.serif.com/index.php?/topic/64885-scripting/page/20/#comment-1086758
However, it recently also occurred to me that there seems to be a potential capability that hasn't been utilized in any image editor that would also essentially provide this capability, but with many advantages. That would be to use GLSL fragment shader scripts. I believe you would be able to do all the things requested above, but with far better performance and entire libraries of effects already available as scripts across the web.
Just curious if this has been considered and what are your thoughts? Seems Affinity might could be the first to offer the capability. This might not fit into the first feature set of core scripting, but hopefully something for future consideration that might be a nice unique feature.
We are planning to allow custom live filters at some point. It would be possible to write one that used GLSL.
- Bryan Rieger, David Cake, debraspicher and 3 others
-
5
-
1
-
17 hours ago, rui_mac said:
In other applications I use, that allow for scripting (mainly, Cinema 4D and VizRT), besides being able to create scripts that can be executed from a menu listing (Cinema 4D, only), I can also attach a kind of a "tag" to an object that runs scripting code in real time, whenever the scene/document is changed/refreshed.
That way, I can perform scripting operations on the object that the "tag" is attached and also on its children.
Will Affinity scripting abilities only allow for scripts that can be invoked from a menu or will we have a new type of "tag" to attach to our "layers/objects" that can allow us to add abilities/behaviours to any "layer/object"?We have no plans for layer/object-specific scripts. However, scripts will be able to run in the background and respond to events such as "document changed".
Could you perhaps give an example of how such a layer/object-specific script would be used in practice?
-
On 5/28/2023 at 6:49 PM, Frozen Death Knight said:
@Jon W A question about the API, will it be possible to add functionality to already existing tools? For instance, let's say I wish to use Expand Stroke every time I vector brush in Designer, will it be possible to implement that kind of automation through scripting?
We currently have no plans to allow customisation of existing tool behaviour.
However, your wish could be easily realised by a script which performs the Expand Stroke command in response to a notional "object created" notification.
-
On 5/12/2023 at 7:40 PM, v_kyr said:
Maybe we should collect some ideas for possible sample scripts, which then could also come along the API & JS scripting docus as so to say reference examples (?).
Yes - please do all feel free to post your scripting-related feature requests here! Whilst we can't promise to implement them all, it would be great to get an overview of what our customers want and expect from scripting.
-
3 hours ago, fde101 said:
If done correctly, scripts will simply be plugins with less verbosity involved in introducing them into the system, compiled on demand or interpreted (depending on the language implementation) rather than being pre-compiled.
This is the approach we are taking. In our world, scripts are just interpreted plugins, with the exact same capabilities as compiled plugins.
- CM0, Frozen Death Knight, shushustorm and 4 others
-
6
-
1
-
18 hours ago, fde101 said:
For an example of how this might be done, consider the way Apple's documentation for many of their APIs is set up. They have a page with a description, but there is a toggle at the top to show the headers and examples in either Objective C or Swift format (as those are the two languages they are supporting). I would expect something like this to be reasonably straightforward for Serif to provide.
This is indeed what we are hoping to do.
- debraspicher, shushustorm, PaoloT and 4 others
-
6
-
1
-
42 minutes ago, v_kyr said:
As far as you also document the plugin SDK accordingly and in a well reusable manner, otherwise it will be useless!
The SDK will be fully documented. In fact we expect it to share documentation with our Javascript library, which is largely a wrapper for the SDK.
- A_B_C, Seneca and debraspicher
-
3
-
32 minutes ago, fde101 said:
Brushes are already parametric in some sense: if you double-click on a brush in the Brushes panel you get a set of parameters that are being fed into your existing brush engine, for things like brush width, size variance, etc.
In some sense yes, but the term "parametric" in the context of editing usually implies that parameters can be changed after the fact (e.g. live filters).
31 minutes ago, fde101 said:When a scripted brush is in use, those parameters would need to be fed into the script so it can determine how to render the brush, but different scripts will want different parameters, so there would be a need to let the script customize the set of parameters that the user can choose from within that editor, replacing the standard ones that are used with the integrated engine. That much would be an essential addition to make this worthwhile.
Agreed.
40 minutes ago, fde101 said:The lack of ability to change the parameters of the brush after the fact would become a particularly strange omission in light of scripting, so the other piece that would be good to have would be the ability to re-open the brush editor for strokes already on the canvas to adjust the parameters after the fact. This could indeed be done for the existing brush engine just as easily, but in my opinion the concept of scripted brushes adds emphasis to its desirability.
I agree that such a feature would be a good match for custom brush plugins, but still independent. You might like to raise it on the Feedback and Suggestions forum.
-
41 minutes ago, NNN said:
So, you won't support it directly as you will support JavaScript?
As I said last week: we aren't ruling out built-in support other languages eventually, but we have no current plans to.
However, any third-party "interpreter" plugins will have access to all the same capabilities as the built-in ones.
- chessboard and Petar Petrenko
-
1
-
1
-
On 4/21/2023 at 3:58 PM, fde101 said:
Another thing to consider: a coded/scripted brush engine.
Hi fde101,
Thanks for your suggestion. Custom brush engines is an interesting idea and we've added it to our list.
Quote* One thread updates a path object tracking the movement of the mouse, and if the other thread is generally lagging, displays a thin version of the path between the last point that the path was at when the other thread last provided data and the point where the brush is dragging through.
* The other thread takes whatever is in the path object and calls the scripted/API-coded subroutine with that path and any parameter values that were set for the brush. The subroutine applies the path to the underlying image data and generates the image (or vector shape) which is temporarily rendered onto the canvas when the subroutine completes. It then waits for the path to be updated or the brush application operation to complete.
When the operation is complete and the final path has been processed:
* If the brush is being applied as a raster/pixel brush and it generated a raster image, it is applied to the pixel layer; if it generated a vector shape, the shape is rasterized and applied to the pixel layer.
* If the brush is being used as a stroke for a vector shape, the output of the subroutine becomes the intermediate representation of the brushed path, whether it is pixel data to be drawn along the path or a vector path to be drawn as a shape; it would become an object of it own if the user chooses "Expand Stroke", etc.
Pretty much how the existing brush engine works, unless I'm missing something?
QuoteIf the path changes, or if the user adjusts the brush parameters while the object using it is selected, then the subroutine is simply called again with the new path and parameters to generate a new representation.
This sounds like a general feature request for parametric brushes, which would be equally applicable to the existing vector brush engine and not really specific to scripting.
-
On 4/14/2023 at 1:29 PM, Ezbaze said:
Will there eventually be support for Python and not just Javascript?
Hi Ezbaze,
We'll have our hands full with JavaScript for the foreseeable future, but we aren't ruling out other languages eventually.
In addition, the JavaScript engine is itself implemented using our plugin SDK, to which we plan to add support for alternative scripting engines (i.e. you could in theory write your own plugin to support Python or any other language).
-
On 4/12/2023 at 2:50 PM, Intuos5 said:
Will the various scripts eventually also be exposed to the keyboard shortcuts of the software? That would make it very versatile if you can call each and every possible function that can be made through scripts from a shortcut (without arbitrary requirements of using Function keys or holding one or two particular modifiers).
Hi Intuos5,
Yes that's correct - the plan is that commands exposed by scripts/plugins will appear in the Shortcuts settings page, alongside native commands.
-
On 7/3/2022 at 9:24 PM, ahnay said:
its expanding to canvas size i believe. there must be someplace hidden to turn that stupid function off.
That sounds like you're using the Crop tool in "Resample" mode. The other modes should just crop without resampling.
-
On 8/6/2020 at 3:43 PM, GoldenDesigns said:
@Jon W Thank you so much is working ❤️
i hope fixes this in next update
Hi @GoldenDesigns, thanks for confirming. This should be fixed in the next update.
-
Hi @GoldenDesigns,
It's possible that this problem is caused by changes to tablet input in 1.8.4.
Please could you try following the instructions in this post:
- SPaceBar and GoldenDesigns
-
2
-
15 minutes ago, Aftemplate said:
You may not know...
Windows lnk api pressure sensing level is limited to a maximum of 2048 levels.
This is a devastating loss for the 8192 pressure pen. Because of Microsoft's restrictions on this API.Windows lnk spatial precision is also pretty bad - technically it's sub-pixel, but in practise you only get about 2 points per pixel.
- SrPx and Aftemplate
-
2
-
On 6/26/2020 at 7:32 PM, AlainP said:
In the latest release as soon as I click "Alt-Left click" (on the Pen) the cursor stays as a color selector tool and I can't draw anymore. The mouse cursor is also displayed as a color selector tool. When pen pressure is enabled the cursor flashes rapidly when I hover over the drawing or photograph. It's very annoying and makes you get away from the computer after a few minutes.
I wonder why this has been changed as it was working perfectly in the previous version.
Hi @AlainP,
Both these problems have been fixed in 1.8.4.674.
The reason we have changed tablet input in 1.8.4 is to improve the precision of pen strokes (see @Aongus Collins' example above).
Originally we had a Wintab-based "high precision tablet input" option, but this was unreliable so it was never enabled by default. In 1.8.0, we tried replacing that with a Windows Ink-based solution, but that brought its own problems. So in 1.8.4 we have returned to Wintab and fixed the original problems.
It is still possible to use Windows Ink, by running Affinity with the --disable-wintab option and turning on Windows Ink in the tablet driver settings. This is worth a try if you're still having problems in 1.8.4.
There is currently no way to return to the "low precision" tablet input that existed in 1.8.3 when Windows Ink was turned off in the app. But given the poor quality of the resulting brush strokes, that is perhaps not such a great loss.
-
-
Only Photo and Designer so far.
-
To all users who have experienced this problem: please don't delete any fonts or rebuild the font cache. The current beta should fix the problem without doing that. If it doesn't, please let us know!
Thanks.
-
We will be investigating this issue. There are many aspects to consider.
Scripting
in Feedback for the Affinity V2 Suite of Products
Posted
Hi @kimtorch.
We are doing our best to engage with our users and understand their requirements.
Our primary focus is to expose existing application features to scripts/plugins; text support is just one part of this. We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts. So you might have to explain some things that may seem obvious to you.
We are aware of InDesign text tags: as I understand it, they are primarily used to map to text styles on import.
What we're trying to understand, and I hope you can explain, is how this relates to scripting. I would guess that perhaps you envisage a script which would run as a tagged text import filter, overriding the tag -> style mapping which would normally be set up manually in the app?