hawk

YES YES YES! 🥴 (joking of course, lots of people did want JS after all) Nice! That sounds like I could write a Swift package wrapping that API. The same could probably be done for Python and others. That's great to hear! Send my regards to the programmers, I really appreciate their painstaking work! Thanks for the update, @TonyB !

Good stuff. Really, I skimmed that article and it looks like a great resource/tutorial. However, it really shows that Swift is far from well-suited for OS scripting, or at least for interoperating with shell tools/processes. The amount of boiler plate required to get piping to work is just outrageous. If you're going to use Swift for scripting, you'd better try to stick with the built-in frameworks as much as possible. And even with that there are portability issues because Foundation is slightly different on macOS than Linux or Windows. 🫤

@fde101 Nice! Swift is getting improvements to its static abilities (build-time constants for starters) in the near future, so I will try to bring this up during those discussions. The closest thing to this right now would be enums, for which every value has to be named, or property wrappers, which are not statically checked. I agree now that JS is one of the worst, and Lua would be a good choice. I've been using Lua a bit with the macOS scripting tool Hammerspoon.

@fde101 I somewhat agree with you. I learned a bit of Pascal in high school, it was fun. I've never used Ada but I read through the introductory pages and I kinda like it, but I noticed that many of the features it boasts exist in Swift. Of course, Swift doesn't have a clear distinction between declarative and imperative code as does Ada, but also nothing is stopping you from organizing your code that way. Descriptive block statements (like if ... then ... end if versus if ... { ... }) can be nice but that could be remedied with inline hints in modern code editors if you really needed it (don't know of any examples though) like they already do for type inference. I don't think Ada would be a bad choice for Affinity. There are surely some things that it's simply the best at, and that's not necessarily limited to industrial / safety-critical applications. But if we're going to eschew weakly-typed and popular "scripting" languages like Python, I would submit Swift for consideration as a balanced middle-ground, with its bidirectional type inference, and less rigorous rules. Personally I find that the strong type system and other compiler features help quite a bit in catching mistakes during refactoring! I almost always get errors when I change stuff around and addressing those errors usually ends me up in the right place. (Sometimes the compiler just refuses to parse a large/complex expression and doesn't give you any helpful pointers though. 🥲) Of course, the other mentioned languages, like Kotlin, would be pretty equal contenders in that regard as well, from what I've seen. I'm not a Swift shill as some have previously in this thread accused me of being.

Yes, you understood it precisely! I would add another scenario, an extension of Scenario 4, just to illustrate what happens when the user zooms out again. Scenario 5: User sets the brush size to 64px. User sets the functionality ON. User sets the zoom to be 200%. Software resizes the brush to 32px (or whatever the maths works out to be). User sets the brush size to be 40px via the Context Toolbar drop-down/field. Software sets the brush size to 40px (exactly what the user set it to be irrespective of the original brush size). User sets the zoom to be 100%. Software resizes the brush to 80px (or whatever the maths works out to be). Thanks for hashing out the minute details of this feature with me. Also, to address your earlier point, with this model I think there would be no problem if it was added to other brush-based tools as well, because it'd be no different than manually resizing the brush. In other words, it's a "stateless" feature. Nothing extra is stored. The only thing that is stored is the current size and your existing brush presets, which aren't touched by this feature. (And of course the toggle state itself is stored like other tool settings.) Unless you meant that changing the brush size on its own doesn't make sense or is unusual for some reason, for vector brushes? I don't know, I'm not really an artist myself, more of a mock-up / programmer art / sketch user, as you can maybe tell from the difference between your profile picture and mine. 😅 Personally, I'd probably only use this with the selection brush tool. Thanks for your supportive words.

Thanks for your discerning inquiry! I think there would always be a single source of truth for the brush size, which would be either in document pixels or screen pixels, depending on which works best for the developers. The text box would always show document pixels like it does now. Then if you enabled it, nothing would happen until you zoomed in or out, and you'd see the brush size automatically change proportional to the change in zoom level. Likewise, when you turned it off, nothing would immediately happen. It would just keep the brush size fixed relative to the document, and the cursor brush outline would scale when zoomed, as is the case today. So to answer all three of your questions, toggling the option on or off would preserve the current size, and the app would not keep track of two different settings. (This is how it works in Blender, by the way.) How does that sound to you? A small toggle button would be good. Not sure about the icon but a zoom lens kind of makes sense to me.

Even if you remove all constraints (by deleting the objects even), the constraints group doesn't become a layer and there's no way to convert it back to a layer. I suggest that the "Promote Group to Layer" menu item should work on constraints groups if there are no more constraints.

The 'New Document' panel appears on the same virtual desktop it was last opened on, which can be different from the desktop which the main window is currently on. This happens only if Affinity Designer is not assigned to a desktop (i.e. if you click the Dock icon and Options -> Assign to: None is selected), which is the macOS default. Note: this is without macOS fullscreen. Steps to reproduce: Launch Affinity Designer. Create a new document (File -> New). Open Mission Control and move the Affinity Designer window to a different desktop. Create a new document again. In the unified window mode, the new document is added to the existing window. Furthermore, if the existing window was minimized in the Dock, it is automatically un-minimized and you're automatically switched back to that desktop. In the separated (floating panels) window mode, the new document is created in a new window on the same desktop as the 'New Document' panel. However, if you subsequently click and drag the title bar to reposition the new window, the new window may suddenly be warped back to the original window when you release the left mouse button (this doesn't happen consistently). Demonstration: new-document-spaces-glitch-compressed.mov If the 'New Document' panel simply opened on the current desktop, then these issues could be avoided. Also, if you're using Affinity Designer in native macOS fullscreen and you open the 'New Document' panel, it kicks you back to the last desktop. You then have to manually switch back to the fullscreen space to see your newly prepared document. Question: Is it not possible, and would it not be better also in this case, to show the panel on top of the fullscreen window?

Thanks! It just occurred to me that this happens without the Transform Objects Separately option too. So it's just about transforming objects inside symbols when the transform/constraints attribute is linked. My next question would be: how should this actually work without Transform Objects Separately? I don't think there's a correct answer... maybe the current behavior is more logically consistent after all?

What about a checkbox like this?

If the same synced object is selected inside multiple instances of a symbol, there is an issue with the Transform Objects Separately option: Transforming the objects with this option enabled, applies the transform delta multiplied by the count of selected objects, causing the bounding box to diverge from the actual result. (if the transform/constraints attribute is linked) While it is true that this can be avoided by deselecting the object in all but one of the symbol instances, that can be inconvenient. For example, consider this scenario: You've got a bunch of symbol instances in your document. Some of the symbol attributes are unlinked (e.g. Text*). You make a multi-selection and start editing a bunch of those unlinked attributes. At some point throughout this process you need to tweak the size or position of the object inside the symbol. Now you need to click to select only one object, transform it, and then reselect all of the other copies, before you can get back to editing the unlinked attributes. That's at least 3 extra clicks, and some cognitive friction. Furthermore: There's no special capability that is unlocked by this behavior. If you want to transform proportionately to the number of objects selected, you could just do that manually. If there really is a great need for this behavior, why is it limited to symbols? Shouldn't it also be available as a general modifier/option on regular groups, layers, etc? This seems like something that could and should be better served by custom scripts if and when those become available. Therefore I consider this a bug which should be fixed by treating the transform/constraints attribute as temporarily unlinked when using Transform Objects Separately. Exact reproduction steps: symbol-transform-separately-bug.mov * Aside: it would be great to have more fine-grained control over unlinking text attributes (and the ability to re-link attributes).

Please add an option to the selection brush (in Affinity Photo or AD/APb pixel personas) to keep the brush size fixed in terms of screen size when zooming in or out. Motivation: when using the selection brush I often find myself zooming in to work around delicate areas. This is almost always accompanied by manually decreasing the brush size proportionately. (Then the process is repeated in reverse.) Perhaps this could be extended to regular pixel/vector brushes, similar to Blender's sculpt brushes. (Blender also has a circle select mode which is fixed relative to the screen.) I know Blender is a different type of software, but it's the only example of a feature like this that I know of.

I'm having these stalls all over macOS since I got my M1 and I thought it was just me because I asked around and nobody else seemed to be experiencing it.

I'm seeing the same issue on Apple M1 with "Metal compute acceleration".

The hardware acceleration issue affects macOS too, at least on my M1 MBA. But even with acceleration turned off, I often find the blur brush tool too weak for my purposes, even with the basic brush.