fde101

Yes, for sure.

I am familiar with a number of programming languages, scripting and otherwise. I have an almost irrational hatred of the way that Python uses indentation as part of its syntax, and accordingly have zero interest or intent of ever wasting my time learning that or any other language which suffers from this same design flaw. It is bad enough that Makefiles use tabs as part of their syntax. I don't like the C-like languages either, and JavaScript is an absolute disaster of a language, but I am more willing to put up with those when necessary than to put up with Python and its ilk.

As has been pointed out a few times, the Scopes panel has the same issue, in addition to being much too small at its fixed size.

Depending on the reason for saving multiple versions of the file, one alternative that might help with this is to save snapshots within the file instead (Document -> Add Snapshot) and just use the regular Save command. This doesn't cover all use cases though, so it may or may not be appropriate for your particular situation. I should also point out that not every workflow has the same requirements on this: I have a situation (with a different program) where I regularly open all files from one folder and export them to a different folder. Everything opens from folder A and everything exports to folder B, but A is not B.

For photos, none, as they are inherently RGB by nature. For other forms of art, better control of the color mapping as long as the correct color spaces are maintained throughout the process. One RGB value might map to several different CMYK values and if you are working in RGB space and relying on the automatic conversions there is no real control over how the ink mixture is obtained. I tend to agree that the majority of users could easily get away with RGB/16 instead of CMYK/16, but not all users are in the majority, and some may be fussy, and may even have legitimate reasons to be. I don't disagree with the request (even if I am in the majority that doesn't need it myself), but I do disagree with the pointless duplicate threads being created for the request.

As an output format, no. CMYK is almost entirely print-oriented and printers simply don't have that kind of dynamic range or color precision, at least not at this time. As a working format, however, there is a legitimate reason to consider it as it can help to reduce problems caused by round-off during calculations being performed during intermediate steps, as @Bound by Beans pointed out above.

Please search for existing requests and add to the existing threads when there are duplicates instead of creating new ones. This has been requested multiple times already.

True, it does allow things other than unlocking them to be done, but in this specific context the assumption is that the OP wants to unlock objects, and only a subset of them, rather than all of them. We would need the OP to clarify if otherwise, but if they only want to unlock ALL of them, they can use the existing command. The point was not that the command suggested would have no value, but rather that it would not solve the problem at hand, based on the assumption that the OP wants to target *specific* locked objects rather than the entire set of them.

Agreed, to a point - this has been brought up before as well, and there are limitations to that being one simple command. You would need something more like "Select First Locked Object" and "Select Next Locked Object" (or even just "Select Next" if it does a "Select First" when a locked object is not already selected) in order for it to be effective for something like this. If the command selects ALL locked objects, it doesn't really provide any advantage, in this context, over the existing "Unlock All" command in the Layers menu, which would do it in one step instead of two.

No, the OP wants to be able to do it without going to the Layers panel, and made that fairly clear. Evidently it is too hard to remember that Command+L (presumably Control+L on Windows) is available from the keyboard at any given time. Adding in particular an Unlock item to the context menu on the canvas where you currently can't select the item anyway (this of course being what I think of as one of the biggest benefits of locking something - that it doesn't interfere with your attempts to select something else) seems like putting the cart before the horse, and adding a Lock item there seems to me like an accident waiting to happen when someone hits it without realizing what they selected then suddenly can't select their object anymore and doesn't realize why. I haven't searched for this particular combination directly (Lock/Unlock from the context menu over the canvas), but I'm fairly confident that direct selection of locked objects has been previously requested, and with all of the other complaints about the handling of locked objects in the Affinity software, there may well be a duplicate of this out there somewhere too.

I am guessing you are using the Windows version, as this has been previously discussed and is evidently a limitation with the update solution Serif uses on the Windows platform.

All they would need to do is integrate with the existing macOS functionality to track recently used documents, as most "real" macOS apps show the recently used list when you right-click their icons on the dock.

Did you pick up the color (in your Color Chooser) using an eyedropper tool? Those commonly work in RGB as they sample from the screen, so anything you grab with those tools is not guaranteed to be accurate in terms of what is actually stored in a CMYK document. Try opening the Color studio panel (set it to Sliders mode so you can see the numbers) and selecting some of the text instead, as that should give you more accurate information about what is actually stored for the text behind the scenes.

Is your document set up for RGB or CMYK? Check this in File -> Document Setup and look under the Color tab. If the document is set up as RGB then this may be an artifact of color management.

If you are using artboards, it always clips objects that are half-on half-off the artboard; there seems to be no way to turn that off - but objects which are completely off the artboard are visible. If you are not using artboards, including when you are using pages in Publisher, this behavior is controlled by the Clip to Canvas setting under View -> View Mode; if items off your page are invisible, turn that off if you want to see them. That option is available in all three apps, though it is disabled when artboards are in use.

... as a legacy format that they do not recommend using for new images. See the quote at the bottom of this Reddit thread: https://www.reddit.com/r/AdobeIllustrator/comments/axohrg/comment/ehuwz6h/

If such a feature were integrated into the application (which, again, I don't think is the most optimal choice here), wouldn't it make more sense when choosing such a font to copy it into the document or some related resource directory to use it locally after it is first selected?

Some font managers are designed to integrate with design software and automatically enable and disable fonts as programs or even documents are opened and closed, but this does not currently seem to be feasible with the Affinity products. Rather than saddling the products with the need to become their own font managers, I believe the developer time would be better spent on fixing whatever is preventing font manager integration from working. This can happen regardless as different operating systems have different sets of fonts included with them, and different web browsers use different default fonts. Even if you are using a "standard" font for your operating system, it may not be available for someone else who views your site. Accordingly, when you care about such things, it is a good idea to test your web pages using multiple computers (or virtual machines) running differing operating systems as well as on other relevant devices whenever it is feasible to do so.

On US keyboards it is the bracket keys [ ] as it is in most software of a similar nature. I know that other users have posted that these are not convenient or do not work on certain international keyboards, so YMMV.

The Affinity apps originally supported this in practically all of the entry controls for numeric values, but Serif intentionally disabled it at one point because people who were using the scroll wheel to... err... scroll... were accidentally changing values as the fields passed under the mouse pointer during that scrolling action. Back when they made that change there was a lot of discussion about this and many of us suggested alternative ways to handle this without losing that functionality entirely, but Serif opted for simply disabling that functionality instead.

The file formats are one in the same, so as @PaulEC suggested, you can simply open the Designer document in Publisher to access its text tools. File -> Edit in Publisher from within Designer, then File -> Edit in Designer from within Publisher, makes it fairly simple to pass the document back and forth between the apps, or if you only need the Designer persona, you can access that within Publisher itself.

I think the point I was mainly getting at was the generalization implied by this. You make it sound like this is something which impacts ALL artists and that the tool is useless for producing artwork because of it. This is not the case. Not all artists require the things you are requesting. That was never meant to imply that they are not things which impact your particular workflow or the more specific type of work that you do. Based on that, it does sound like you have a specific use case which requires this feature which not all software has (with the Affinity suite currently among those which do not have it). This does not mean that artists in general require this feature, but it does mean that for your particular way of working, you do. There is nothing wrong with that, and it is a perfectly reasonable request to be making, but I've seen far too many threads like this one in which people make blanket statements on behalf of a large group of users when they quite clearly apply to only a subset of that group, and that clear generalization of its impact to a larger user community than that actually affected is something that should probably be tempered a bit.

I wonder how often Michelangelo and Picasso used the HSV color space...

Seems like this would be a good addition to preflight.

Shouldn't this be in the bug report section of the forum? This section of the forum is intended for feature requests.