fde101

The option+click to pick the key object should really be listed in the help bar across the bottom of the window too.

The price itself is not as important as the pricing model. CC is a subscription-only offering, and for me, that means it is a dead product. Even if it were a penny a month it would be too much. If the Affinity suite cost three times as much as it does it would still be an offering to consider as it is perpetually licensed.

That is a UI convention but I don't believe it is a valid reason for the guides to have been designed like this; they could simply have come up with an alternative method of deleting them, such as dragging them all the way back to the ruler. A more likely reason is that multiple artboards are spread out in a large area and may not match each other in dimension or be aligned in their placement. If guides were visible outside the artboard they would cross over other artboards, meaning you could either give a potentially misleading perspective on where the guides were relative to the other artboards if the guides remain local to the artboard (it could be distracting if they cross over objects slightly off and the user keeps wanting to go and fix them only for the guides to change as soon as something on the other artboard is selected), or if the guides were made global, then they would not necessarily align to all of the artboards in any meaningful way - put various different sizes of artboards on the same canvas, and the guides would only make sense for a few of them at most.

If your artboards are all the same size, you might consider creating a multi-page document in Publisher instead and putting the guides on a common master page, so they can be shared between pages.

No, more of a dynamic asset panel that displayed content from a user-specified folder on disk rather than from an Affinity-specific asset store.

That is not quite what was being asked for, but the request was a redundant insertion of an irrelevant topic that is already being covered on another thread so likely best ignored here to avoid further polluting this thread.

Thanks, and yes, I have also pointed out the possibility of using KM for various things people were asking for, but it is not really ideal in a lot of those cases with the current relative lack of keyboard shortcut / scripting options in the Affinity products. Some things it can do very well, others it can kind of act as a kludge. The addition of scripting support should significantly improve the possibilities. Perhaps a moderator could move this thread to the Tutorials section - but at least this helps to explain what the thread was meant for.

I'm a bit confused by this post... are you posting a tutorial/example for other users (in which case it belongs in the tutorials forum - https://forum.affinity.serif.com/index.php?/forum/9-tutorials-serif-and-customer-created-tutorials/) or are you asking for Serif to somehow connect with the developers at Keyboard Maestro to provide enhanced integration with their product? There is already a thread discussing scripting/plugin support pinned at the top of the feature request forums; that is coming eventually. Any tie-ins with Keyboard Maestro or other platform-specific utilities would most likely need to be derived from that more generic scripting support. I would not expect Serif to provide direct specific support for KM or other similar utilities, but the plugin support may provide a mechanism for the KM developers to provide a better tie-in with the Affinity products, at which point you could request that of them. You may not even need that plugin to make more effective integration possible, however, as KM can already execute arbitrary AppleScript code, and Serif suggested at one point that while they seem to have decided to use the relatively pathetic ECMAScript language as the basis of their scripting support, they will at least provide one AppleScript command to execute provided ECMAScript code against their scripting engine, so that might provide the hook needed to perform tasks more directly using the AppleScript support in KM.

I would imagine that more people know how to read an analog clock than polar coordinates. From a mathematical standpoint the cartesian coordinate system rises up from the baseline also but we don't normally work with software having the ruler measure from the bottom of the page by default.

Not sure that there is really a case for this as the rotation of the wheel is somewhat arbitrary and varies wildly among different products. Here is what the wheels look like in Davinci Resolve which is one of the more typical tools used for color grading video: Here is the wheel in the Apple color picker, with yellow a bit to the right of the top - note that the colors go in the same direction as Resolve and the opposite direction from the Affinity products (the Affinity products go purple-red-orange-yellow clockwise, these go counter-clockwise): Capture One is organized like the Apple color picker: So is GIMP: Corel Painter - note that this one places yellow in roughly the same place as does the Apple Color Picker, GIMP, and various others, but the colors run in the opposite direction, as they do in the Affinity products: With the wide variety of orientations that are used, no matter what the Affinity products decide on, they are going to be different for *someone* who goes back and forth between them and some other relevant product, so there is not really any point in trying to sync it to anything in particular.

Without having dug in too deeply, my guess would be that either softness or light bleed around the edge of the product may be tricking the algorithm that detects where the focus changes and causing the software to perceive that part of the image as being background, thus blurring it. It may be possible to improve the algorithms to better detect those edges, but it is unlikely that they will ever be 100% accurate for all cases, so some manual refinement to the edges will likely always be needed in some cases.

Still no giraffe tool.

This would be the macOS version running under macOS with the iPad as an external display; it would not be the iPad version of the app.

Agreed, along with variable fonts, and this has been brought up many times in the past. For something like this particular example you can use a normal font and make the text a mask for a picture (in this case of a flag) behind the text, but it would obviously be more convenient to use a pre-rigged font like that, and other examples of color fonts may not be quite so easy to mimic in that manner.

Serif has stated in the past that they were not happy with the results they were getting from tracing using the algorithms they had on hand and that when they introduce this into the Affinity suite they want to do it right and have something better than what they could achieve right now. There were also hints that they intend to do this in a big way and implement it as an entirely new persona just for this task. This was some time ago, however, so not clear what direction this may currently be taking - still, I would expect this will come in time, but they are waiting until they can do it in a way that they will be happy with, which I can certainly get behind.

We need a "You're welcome" reaction. Responding to "Thanks" with a "Like" reaction seems to indicate "I like being thanked..." which is kind of disingenuous... on the other hand a "Thanks" reaction to a "Thanks" post is more like "thanks for the thanks" which doesn't seem quite right either. 🤔 No problem!

For a Group, you need to select something within the group, not the group itself, for this to work. Alternatively, with the group itself selected, enable "Insert inside the selection" from the toolbar. It does work as @Alfred describes it for Layer and Artboard layers.

Fair enough, so why not "Overriding Lock Children"? There are better ways to accomplish this than the grammatical assault.

Real flowers are not truly symmetric.

More essential than text boxes, rectangles and lines?

So... if you have an artboard with a position which is not pixel aligned to the canvas, but it contains objects which *are* pixel aligned to the canvas, then those objects are not pixel-aligned to the artboard. This would result in modified dimensions when exporting using the Export persona (but not the potentially unwanted aliasing), but aliasing when exporting via File->Export (due to the objects having non-aligned positions with respect to the artboard) though the dimensions would be correct. While logically this makes perfect sense, it is ultimately a lose-lose situation for what I would assume to be the majority of users. Agreed. Also with other mechanisms that may impact artboard size/position. This can be tricky to get right across the board, however. If the resolution (DPI) of the document changes, artboards which were originally pixel aligned may no longer be aligned. For example, if you change from 200 DPI to 300 DPI, then an artboard which was at (1,1) would now be at (1.5,1.5). Adjusting the position of the artboard to compensate may throw objects on the artboard out of alignment when they otherwise would have been aligned... and the complexities continue.

Making the header areas a bit darker and making the active tab names and collapsible area titles bold would probably be small changes that could go a long way toward improving the navigability of the panels. I find the current scheme sufficient for myself but I can easily see that others may have more trouble with the current scheme. I still contend that adding color to these areas would be a mistake.

Not really, because it introduces an entire area of color to the interface where it is not needed. More contrast may be good, but the overall cast of the bulk of a professional UI for an application which deals with color should be kept as neutral as reasonably possible, to avoid throwing off the user's perception of the color in the elements within the document. With some things, such as color wells, there is no choice. Small amounts of low-saturation color in a few places such as icons may be OK for many users, but it is good to have an option to disable that and make them gray, which the Affinity products do offer in Preferences.

Maybe an indicator could be added to the mouse pointer when over the wheels showing a filled rectangle or an outline to indicate whether the fill or stroke is being set?

Thing is, being on such an easily pressed key is what makes the feature so useful. You can quickly toggle the visibility of much of the UI in order to see more context around what you are working on, then quickly bring it back. It is probably more valuable on smaller screens than larger ones, but regardless, it is a nice touch once you understand it. When you first open any of the Affinity applications the welcome box offers a link to a set of video tutorials, the very first of the "Basics" tutorials is an overview of the user interface in which various ways of accessing and arranging panels, as well as the use of the tab key, are all explained: