fde101

Some of us have seen the evolution (including ingestion of 3rd party technology) of other companies' graphics suites, such as CorelDRAW and PhotoPaint (current relabeled Corel Graphics Suite).  I first used CorelDRAW 3.  Not 13, not X3, not 23.  Three.  In comparison to the current CGS it was a kludgy, ugly, inconvenient, limited and annoying piece of software.  The CorelDRAW 5 release was a tremendous step forward.  Over the years, it has evolved to the point where I don't even bother looking at new releases more than every 4 or 5 years, because it's stable, reasonably comprehensive and I don't care for UI tweaks just to accomodate the latest trend (flat buttons, dark mode, disappearing scrollbars, no thank you).
A user of CorelDRAW 3 would be justified in bitching about missing features, counter-intuitive UI design, awkward controls, and bugs.  But if they predicted that CD would never be usable, and no professional would ever consider it in the future, they would be quite incorrect.  Despite Corel's persistent corporate mismanagement, they manage to maintain some perfectly usable software.  They brought in technology from Xara, which added a lot of functionality (and, I believe, considerable numeric stability).  There are aspects of CorelDRAW I consider superior to the industry reference (and 800lb gorilla) Illustrator.  They also completely abandoned Corel (formerly Ventura, formerly GEM) Publisher, which is what drew me to the Affinity suite in the first place.  Some good decisions, some bad decisions.
Everybody has their own list of "must have" features.  Release 1 of the Affinity Suite didn't have some of the things on my list.  That did not make it useless, because not every job requires every tool.  But it did mean I had to fall back on other SW to do some of my work.  Release 2 has filled in some of those missing pieces, but some of them are still quite rocky and I'd hope for continued improvement.  There are still things missing, but I can do more of my work in the Affinity suite, and I expect this progress to continue.
Meliora spero, it's not for you to decide that Affinity is dead.  That's a decision for the marketplace.  And it's not going to be decided by Affinity release 2 any more than the life or death of CGS was decided by CorelDRAW release 3.  Furthermore, you are not accomplishing anything by repetitious venting about how you think Affinity is dead.  You've made your opinion crystal clear. While my "must have" list is undoubtedly different from your, the Affinity suite is missing some essential features.  Unless your principle is "misery loves company" and your object is to make everyone else miserable, consider your point well made and drop it.

Image layers have their boundaries distorted but the pixel data within them stays locked in place.  Pixel layers ignore the distortions entirely.  Bitmap fills also ignore the distortions.  None of these behaviors are ideal in most cases, though it is nice having them as an option as there may be times when they are useful (just not as the only or even default option).

As I understand it, in Japan it is common for people to say (the Japanese equivalent of) "blue" when they actually mean "green" - traffic lights turn green just like they do in other countries but in Japan the people would say they turned "blue".  It is a rather curious part of that culture which may not make sense to anyone else.
 
Windows is still not macOS, and is thus inferior, but does that mean that people using it are being "abused" by Microsoft?
They are using an inferior product for sure, but that doesn't qualify as abuse.
 
There are numerous reports of issues with this 24H2 release of Windows 11, some people going as far as reformatting their drives to try to get back to an older version because of all the problems it is causing - it is evidently a bad release, yet Microsoft continues to push it to people's computers.  Is that abuse?
 
I don't believe it is remotely accurate to say that the release versions of the Affinity applications are abusive.  Nevertheless, Serif could definitely stand to make some serious improvements to their development and release practices.  The list of known defects with a beta are far too long when they switch to release candidate status, much less put out an actual release.
The goal should be zero known bugs (newly introduced or otherwise) at the time of any release.

The Warp Group feature in Affinity Designer is very powerful and is an advancement over Illustrator's clunky panoply of warping methods and it can be further exploited as a differentiator. The best part is the non-destructive nature and the way that more things can be added to the same warp after the fact. I love that live FX like Gaussian Blur can be warped along with the shape and I'm just starting to discover how powerful that is.
One problem is that several things are not supported by the warping. The biggest one lacking is Gradients. An object with a Gradient fill or line is not warped along with the object shape. It would open up many possibilities if the warp could be applied to gradients too. I don't think that bitmap objects are affected by the Warp either. Are there other things that are immune to warping?
Another idea that I would love to see is the ability to assign color values to the node points on a mesh. This could be a very interesting and useful way to customize vector objects with complex shading. It would essentially match and surpass Illustrator's Gradient Mesh tool by being much more flexible and powerful. 

It is from a certain perspective, because the message that was responded to did accurately spell out what it would do, so a failure to read that message carefully resulted in the product doing... exactly what it said it would do.
Admittedly, that was not the case (at least not in terms of the final end result) for @Old Bruce and his attempt to explore this feature.  What happened to him sounds like a more serious design flaw (if Serif failed to account for this scenario), or possibly a bug (in the event that Serif had attempted to account for this but their attempt to do so is not working as intended).
 
If all you do is what everyone else is doing, then why do it at all?  Sure there are conventions that it makes sense to account for, and consistency with the user interface patterns of the underlying platform is certainly something to strive for, but there needs to be room for differentiation as well.
 
True under normal conditions, but consider that the resource manager is a tool specifically provided for managing those assets, and a function was being used that interacts with stored files, so there is some leeway in interpreting this aspect of the program.  By definition the feature in question is saving files, which alters assets in some manner (by moving their primary presence from being embedded in the document being edited to being stored separately on the disk).
Many programs (such as video editors) which use "linked" assets like this offer tools for manipulating them in bulk on disk to assist users with organizing and cleaning up their storage, and these features all involve some degree of "altering" at least the storage of their assets.
 
Agreed, though this would also create duplication if the assets have not changed from the original names, so the user should obviously be made aware and given control over the decision.
You are missing an option which should be obvious from the situation the OP started with.  He wanted to replace the embedded content with that of the original files which had been updated since being embedded.  For example, three options could be presented:
Rename the embedded assets and save them alongside the existing files.  This will create additional files on the storage device. Replace the embedded assets with the assets from the files already present on the storage device.  This will cause any changes which were made to the embedded assets since they were embedded to be lost.  If the changes are deemed undesirable, the current versions may be recovered by using the Undo feature at least until the document is closed. Rename the files on the storage device and replace them with copies of the embedded assets.  This will create additional files on the storage device.  Any other documents which are linked to these files may be updated to match the content which is currently embedded in this document.

It is from a certain perspective, because the message that was responded to did accurately spell out what it would do, so a failure to read that message carefully resulted in the product doing... exactly what it said it would do.
Admittedly, that was not the case (at least not in terms of the final end result) for @Old Bruce and his attempt to explore this feature.  What happened to him sounds like a more serious design flaw (if Serif failed to account for this scenario), or possibly a bug (in the event that Serif had attempted to account for this but their attempt to do so is not working as intended).
 
If all you do is what everyone else is doing, then why do it at all?  Sure there are conventions that it makes sense to account for, and consistency with the user interface patterns of the underlying platform is certainly something to strive for, but there needs to be room for differentiation as well.
 
True under normal conditions, but consider that the resource manager is a tool specifically provided for managing those assets, and a function was being used that interacts with stored files, so there is some leeway in interpreting this aspect of the program.  By definition the feature in question is saving files, which alters assets in some manner (by moving their primary presence from being embedded in the document being edited to being stored separately on the disk).
Many programs (such as video editors) which use "linked" assets like this offer tools for manipulating them in bulk on disk to assist users with organizing and cleaning up their storage, and these features all involve some degree of "altering" at least the storage of their assets.
 
Agreed, though this would also create duplication if the assets have not changed from the original names, so the user should obviously be made aware and given control over the decision.
You are missing an option which should be obvious from the situation the OP started with.  He wanted to replace the embedded content with that of the original files which had been updated since being embedded.  For example, three options could be presented:
Rename the embedded assets and save them alongside the existing files.  This will create additional files on the storage device. Replace the embedded assets with the assets from the files already present on the storage device.  This will cause any changes which were made to the embedded assets since they were embedded to be lost.  If the changes are deemed undesirable, the current versions may be recovered by using the Undo feature at least until the document is closed. Rename the files on the storage device and replace them with copies of the embedded assets.  This will create additional files on the storage device.  Any other documents which are linked to these files may be updated to match the content which is currently embedded in this document.

I would imagine some users would also find it nice if more of the alignment functionality were available broken out into individual icons so that they could be made more accessible without the extra click to open up the alignment panel.  A fair subset of them are admittedly available already on the context toolbar, but only with specific tools selected.
Different users place different priorities on different tools and functions and have differing amounts of screen space available, so making groups of commands available in popups and individual commands available to reduce clicks would allow users to better tailor the toolbar to their own requirements.

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.

I personally think they should default the title and author fields to blank.

If you create a lot of text frames, in which you always write some value (for example, dimensions), then the current functionality is very desirable - thank you Serif for not forcing me to repeatedly change the completely unnecessary Move tool to the text tool. By the way, why would I need the Move tool after finishing the text? If I need to adjust the dimensions/position of the currently edited text frame, I will do it using the active tool. And if I want to transform another object, I will switch to the Move tool - just like with all other tools.
Edit: The current behavior - i.e. ending creation/editing after pressing ESC and preserving the current tool - is the same and very often used, for example, with the Pen tool when I need to break drawing a line/curve and start drawing another one, or with the Shape tool when I need to draw another shape that touches or overlaps the previous one. The proposed switching to the Move tool after pressing ESC (I assume that the said proposal is systematic for all tools) would be very undesirable, as it would force the user to constantly reselect the desired tool.

For some reason the Typography button on the context toolbar doesn't seem to work for me consistently.  Sometimes it does what it is supposed to, sometimes it does seemingly nothing.
In any case, it can also be accessed using the "..." button in the Typography section of the Character panel, or using Window -> Text -> Typography.
That gives it a whole tab to itself, making its position within the Character panel less relevant, which I suspect may be why it was moved down, to make other, less redundant sections more accessible?

Just be careful when jumping to conclusions like this.  He didn't say anything about what release it was intended for, or even if that had been decided.  Sometimes features can take the time span of multiple releases to complete.  I work for a company where we develop software; it is not even remotely uncommon for us to have things in the works that cover multiple release periods before they make it into the product.  I would expect the same is true for Serif or any other company working on non-trivial software like this.

So is Windows and everything else which relies primarily on ACLs and user accounts for security purposes.
If you want real security, either stay off the internet, or use something based on a pure capabilities architecture.
Sadly, there are not too many of those to choose from today, as people tend to favor convenience, familiarity and tradition over security.

The same is true of Windows.
Internally Windows performs most security checks as the level of a process owner, not at the level of a process.  This violates the principle of least privilege at a low level in the system.
A true capabilities architecture solves this by granting specific privileges to individual objects (memory pages, devices, files, etc.) to individual processes, effectively working at a much lower level than is feasible to accomplish with such an arrangement.
Practically all modern operating systems are fundamentally insecure at a low level.
There may be a few specific privileges (they are generally broad in scope and not tied to individual objects) which are handled at the process level in modern systems, but until that is applied pervasively against each object for each process, the security is incomplete.
 
The so-called "application sandbox" approach is in a sense a recognition for this: it is a high-cost mechanism to try to "bolt on" extra security due to the insufficiency of the ACL model which is too difficult to "fix" in existing OS architectures.
Until we are ready to hit the reset button and rethink the OS architecture from the ground up, our systems are fundamentally vulnerable.
Look up KeyKos or EROS for past work that has been done in this area.  They produced a lot of documentation explaining the fundamental vulnerabilities in contemporary security architectures and ways to solve them using a capabilities approach.

Correct, and for good reason.  When judging color you are influenced by what surrounds that color.  A neutral gray appearance is optimal for a user interface because it minimizes the influence it has on color judgements.  Too high a contrast, or too much color in the user interface, and it becomes untrustworthy, making it hard to take seriously as a "professional" product in the design world.
In short, I would have a harder time taking the Affinity products (or any other design-oriented products) seriously if the interface had too much color in it, or if the contrast of the user interface were too high.
The default user interface has contrast which is just about right for the type of product that it is.
However, I do recognize that there are those using these products who may be working in situations or handling projects where color judgement is less critical or is already impaired by eyesight issues or similar, and who struggle due to that contrast.  Having a high contrast option to choose from in preferences would likely expand the software to more users who are in that situation and ease things for many who are in between.  For some types of design software (ex. video color grading software) it would be the equivalent of braille buttons on cars - if someone is blind they shouldn't be driving - so I can understand why it might be much less of a consideration in such cases, but that certainly isn't the case across the board for these particular applications, and making provision for these users as an option in preferences would not be unwelcome, so long as it does not compromise the product for those who don't need it.

The object styles in the Affinity products are unfortunately not "real" styles.  When you apply one its properties are copied to the object, I don't believe any connection is made back to the style.  If you modify the style the changes are not applied to the objects.
They are more like presets than styles.

As @Bryan Rieger pointed out, there are a variety of options out there and a big piece of this answer will depend heavily on the style of animation you are trying to create, where you plan to deploy it (video, web, UI feature, etc.), and how you want to work with it.
Other programs you might look at are Apple's Motion (video work) if you are on a Mac, or as a second option for hand-drawn cell-based animation on an iPad, there is also Callipeg, which has been around longer than Procreate Dreams.
For more cartoon-like 2D rigged animations there is also the free open-source Synfig Studio which may be applicable in some cases (and that one is cross-platform).
 
Note that this has been discussed before in many other threads, so searching the feature request forum for "animation" will net you many past discussions on this, and other recommendations were likely offered in those past threads as well.

This has come up a few times before, and Serif has consistently indicated (when they responded at all) that they had no intention of introducing 3D or animation support of any kind into the Affinity suite any time soon.
It wasn't quite so closed off that this opinion would never change, but it was close to that, and given how far behind they are on things that are much more applicable to what they had already said they wanted to do, I wouldn't advise holding your breath waiting for this.

As @Bryan Rieger pointed out, there are a variety of options out there and a big piece of this answer will depend heavily on the style of animation you are trying to create, where you plan to deploy it (video, web, UI feature, etc.), and how you want to work with it.
Other programs you might look at are Apple's Motion (video work) if you are on a Mac, or as a second option for hand-drawn cell-based animation on an iPad, there is also Callipeg, which has been around longer than Procreate Dreams.
For more cartoon-like 2D rigged animations there is also the free open-source Synfig Studio which may be applicable in some cases (and that one is cross-platform).
 
Note that this has been discussed before in many other threads, so searching the feature request forum for "animation" will net you many past discussions on this, and other recommendations were likely offered in those past threads as well.

No.
Create the frame(s) on the master page(s) and link to each other if needed. Create one spread using that master and insert the text into the frame(s) that were created on the master. A red triangle appears on the right edge of the last frame where the text would overflow. Hold down the SHIFT key and click on that triangle.   Publisher automatically creates enough additional pages to hold the overflowed content and links the frames together for you.

Not everyone is designing for print.  When working on elements targeting video, cinema, user interfaces, etc., it is more essential to work with a calibrated display and make judgements against that.
For typical video color grading work the "most correct" setup is a separate display showing only the content, without any user interface at all, and to manipulate controls on the user interface and make judgements on the separate display, but it is still necessary even when working that way to sometimes view things on the user interface display, meaning it must also be calibrated as much as possible, and anything that might throw off perception of color within the image minimized.
When using applications like the Affinity apps, that method of working is less of an option, as you directly manipulate the image within the user interface itself, so color judgements on the user interface display become even more critical.  You spend a lot of time looking at the design on that display, and if you spend enough time looking at something while working with it, you lose the ability to make accurate judgements about what you are seeing, as your eyes adjust to it and it "looks" right even when it is not.
Keeping the "first impression" as accurate as possible is very important.

Version 1 and version 2 are separate apps.  If you had purchased the version 1 app and no longer have it installed, you should be able to reinstall it from the purchases list on the App Store.
If you did not purchase it while it was still available, you won't be able to now.
 
All that being said, please search the bug report forum for the problems you are having and report them if no one else already has.  Otherwise they may not be fixed as quickly since they may go undiscovered if others are not experiencing and reporting them.

In addition to the questions @Alfred brought up, make sure you are looking in the list of applications you already purchased (check the "Not on this iPad" tab on the Apps page under your account), not trying to search the store.  A search of the store won't find the version 1 apps because they were withdrawn when the version 2 apps were released.

...wasting everyone's time and contributing to the frustration of the community when Serif completely ignores it, as they have essentially implied a few times would be their likely response to such a thing.
 
Resolve has run on Linux for a long time, even prior to BMD's limited support for it, as the dedicated hardware consoles used to be part of a turnkey system that was the *only* way to obtain Resolve (at very high price points), with software-only download versions for computers coming much later than that.  BMD has invested more heavily, from what I can tell, in providing macOS support than in providing Linux support, but they have made the previously turnkey-only Linux version of Resolve more widely available as a software-only download version, so they are keeping it up to some degree, though their distribution support is somewhat limited.
 
How so?  Adobe's software isn't available on Linux either.  If someone prioritizes the choice of using Linux over the applications, then they aren't using Adobe, so this can't be considered an alternative to Adobe.  If someone prioritizes the software over the operating system, and they are currently using Adobe software, then they aren't using Linux (at least not for that purpose), so they would not be in that "market".
 
They have already done this and determined that it is not yet there.
 
Even a beta version would require most of the development time that would go into a release version, so using one to "test the market" would be spending probably 90% of the effort that would be required to develop the final versions, meaning that they would already be committed to seeing it through, thus it would need to come after they would "test the market".
 
Agreed, and I would suggest this one be closed, as Serif has already done with several others which have recently been created.

...wasting everyone's time and contributing to the frustration of the community when Serif completely ignores it, as they have essentially implied a few times would be their likely response to such a thing.
 
Resolve has run on Linux for a long time, even prior to BMD's limited support for it, as the dedicated hardware consoles used to be part of a turnkey system that was the *only* way to obtain Resolve (at very high price points), with software-only download versions for computers coming much later than that.  BMD has invested more heavily, from what I can tell, in providing macOS support than in providing Linux support, but they have made the previously turnkey-only Linux version of Resolve more widely available as a software-only download version, so they are keeping it up to some degree, though their distribution support is somewhat limited.
 
How so?  Adobe's software isn't available on Linux either.  If someone prioritizes the choice of using Linux over the applications, then they aren't using Adobe, so this can't be considered an alternative to Adobe.  If someone prioritizes the software over the operating system, and they are currently using Adobe software, then they aren't using Linux (at least not for that purpose), so they would not be in that "market".
 
They have already done this and determined that it is not yet there.
 
Even a beta version would require most of the development time that would go into a release version, so using one to "test the market" would be spending probably 90% of the effort that would be required to develop the final versions, meaning that they would already be committed to seeing it through, thus it would need to come after they would "test the market".
 
Agreed, and I would suggest this one be closed, as Serif has already done with several others which have recently been created.