fde101

Rectangular marque.
Begin drawing eks elliptical marque. Hold down space to move the marque to another position. Space bar changes the size of the shape and does not move the shape.
Holding down the spacebar should move the marque.
Click eks Rectangle tool.
Start to draw the size of the shape and hold down space bar to move the shape. One is able to move the shape by holding down the spacebar.
 
Conclusion any tool that draws a shape Rectangle tool, Marque Tool or anything else.
As one begins to create the shape holding down the space bar should move the shape around, so one has better control over where one begins. 
This means the short cuts (keyboard command) for the Rectangle tool should should also be reflected in other tools. As it would keep a nice consistency in regards to similar methods/techniques.
 
 
NB! 
1. One begins to draw out a shape and notices one wants to readjust the starting point.
2. One then holds down the space bar to align the starting point. (moves the shape one is drawing out)
3. One then continues to draw out the shape.
Having a way to adjust the starting point by holding down the space bar is a technique I have used a lot in Photoshop as it helps me to realign where the shape begins.

RE: Rotation gestures - that should already work with touch screen devices (the same with pinch to zoom etc). It won't work on a trackpads, mainly because the hardware doesn't support it, so there's not much we can do about that.

Grids are generally regular in their spacing; you might be better served by guides instead.

Ho @resultsphotography, welcome to the forums!
 
You are in the "Photo Beta on Mac" section of the forum.
 
For the Windows version betas, you should be looking here: 
https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/

Ho @resultsphotography, welcome to the forums!
 
You are in the "Photo Beta on Mac" section of the forum.
 
For the Windows version betas, you should be looking here: 
https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

I don't think I have ever seen anything that compares how effectively iPadOS uses the iPad hardware with how effectively Android uses its hardware.  I would guess as well that iPadOS would be less demanding largely due to the fact that it is not encumbered by Java technology the way that Android is, but that would simply be a guess.
I have seen a similar level of stability issues between the two platforms, but that is for my own use cases on the specific devices I own.  Do you have any research data showing the difference in stability between the platforms?
iPad has better 3D graphics support than android did up until recently.  With the addition of Vulkan to recent Android versions I would expect that from an architectural perspective between the platforms they are likely on par now, but as Android hardware varies so wildly the quality of drivers will come into play, plus as has been pointed out, iPad does have the superior hardware at this point.  For 2D graphics I would guess they are closer to matching, but it would be a guess on my part.
As to being more "safe" and the relative lack of piracy, that is a trade-off: the closed ecosystem of the app store on the Apple platforms makes it easier to control things to the point that fewer risks are taken, but the downside is that they reject a number of categories of applications that are readily available on Android, making it worthwhile for some of us to maintain both platforms as we can do some things on each that can't be done on the other (at least not easily).  This includes things such as some types of network diagnostic tools that will run on Android platforms but which require a level of network access that Apple won't permit under iOS/iPadOS.
 
In this context perhaps, but this is not always generically true.  Some software (including operating system software) can be provably superior when compared to others for specific use cases depending on how their algorithms handle various conditions.
As a simplified example, consider memory allocation.  When an operating system has X amount of memory and needs to distribute it across multiple processes (applications), there are a number of approaches that could be taken.  If a process comes in and says "I need X amount of memory" then the OS needs to find a block of memory to hand to the process.  Depending on how the data structures are organized by the operating system, the amount of time it takes to find that block of memory may or may not be predictable, may or may not have an upper bound on it, etc.  It is also possible that the OS might need to allocate more than the amount of memory requested in order to keep the process of allocating the memory efficient, depending on its goals.
For example, one algorithm might return the exact amount of memory requested if it is available but take an unpredictable amount of time to obtain it, say ranging from 1 ms to 30 ms but normally taking 3 ms or less.
Another might return the amount of memory requested rounded up to the nearest 1 KB but do it in 5  ms every time.
If you are creating a word processor, the "average" performance of 3 ms or less combined with the fact that the first algorithm does not waste as much memory would probably make it a more practical choice.
If you are creating a medical device that patients rely on to keep them alive and it needs to perform some task every 40 ms precisely without fail, the unpredictable amount of time to allocate memory in that same first algorithm could result in someone's death.
Again, this is admittedly a simplified and not particularly relevant example, but these types of trade-offs are all over the place when it comes to the design of a complex piece of software such as an operating system.  Sure taste can come into play to some degree, but there are times when a particular piece of software (operating system or otherwise) is simply not suitable for a particular task, or perhaps is only available to run on hardware which is not suitable for a particular task, and there are times when the choice of algorithms and the set of facilities exposed by a piece of software are simply better matched to solving a particular problem.

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

Thank you for the suggestion. This is in the latest beta.

I don't think I have ever seen anything that compares how effectively iPadOS uses the iPad hardware with how effectively Android uses its hardware.  I would guess as well that iPadOS would be less demanding largely due to the fact that it is not encumbered by Java technology the way that Android is, but that would simply be a guess.
I have seen a similar level of stability issues between the two platforms, but that is for my own use cases on the specific devices I own.  Do you have any research data showing the difference in stability between the platforms?
iPad has better 3D graphics support than android did up until recently.  With the addition of Vulkan to recent Android versions I would expect that from an architectural perspective between the platforms they are likely on par now, but as Android hardware varies so wildly the quality of drivers will come into play, plus as has been pointed out, iPad does have the superior hardware at this point.  For 2D graphics I would guess they are closer to matching, but it would be a guess on my part.
As to being more "safe" and the relative lack of piracy, that is a trade-off: the closed ecosystem of the app store on the Apple platforms makes it easier to control things to the point that fewer risks are taken, but the downside is that they reject a number of categories of applications that are readily available on Android, making it worthwhile for some of us to maintain both platforms as we can do some things on each that can't be done on the other (at least not easily).  This includes things such as some types of network diagnostic tools that will run on Android platforms but which require a level of network access that Apple won't permit under iOS/iPadOS.
 
In this context perhaps, but this is not always generically true.  Some software (including operating system software) can be provably superior when compared to others for specific use cases depending on how their algorithms handle various conditions.
As a simplified example, consider memory allocation.  When an operating system has X amount of memory and needs to distribute it across multiple processes (applications), there are a number of approaches that could be taken.  If a process comes in and says "I need X amount of memory" then the OS needs to find a block of memory to hand to the process.  Depending on how the data structures are organized by the operating system, the amount of time it takes to find that block of memory may or may not be predictable, may or may not have an upper bound on it, etc.  It is also possible that the OS might need to allocate more than the amount of memory requested in order to keep the process of allocating the memory efficient, depending on its goals.
For example, one algorithm might return the exact amount of memory requested if it is available but take an unpredictable amount of time to obtain it, say ranging from 1 ms to 30 ms but normally taking 3 ms or less.
Another might return the amount of memory requested rounded up to the nearest 1 KB but do it in 5  ms every time.
If you are creating a word processor, the "average" performance of 3 ms or less combined with the fact that the first algorithm does not waste as much memory would probably make it a more practical choice.
If you are creating a medical device that patients rely on to keep them alive and it needs to perform some task every 40 ms precisely without fail, the unpredictable amount of time to allocate memory in that same first algorithm could result in someone's death.
Again, this is admittedly a simplified and not particularly relevant example, but these types of trade-offs are all over the place when it comes to the design of a complex piece of software such as an operating system.  Sure taste can come into play to some degree, but there are times when a particular piece of software (operating system or otherwise) is simply not suitable for a particular task, or perhaps is only available to run on hardware which is not suitable for a particular task, and there are times when the choice of algorithms and the set of facilities exposed by a piece of software are simply better matched to solving a particular problem.

Welcome to the Serif Affinity forums.
Discussions in the forums can be near-real-time chats, if people are around. I've seen this happen many times. They're not private chats, of course, but that is also possible by sending someone a direct/private message.
As for trading brushes, etc., people share brushes and other items in the Resources forum already.

Is it just me or does the original post read like some kind of advert for web services? Maybe I’m reading it wrong.
Either way, I agree with dominik and Alfred; my preference is to keep the forums as they are (in relation to social media, live chat and those sorts of things).

To put some context around this, one of the highest-performing Android tablets out there right now is the Galaxy Tab S6, which has a roughly $650 price tag (Wi-Fi 128 GB model) and an OpenCL score of 2299.
The 6th gen iPad (Wi-Fi 128 GB model) - not even the iPad pro - has a Metal score of 2793 (its equivalent to the OpenCL score for Android) and a price tag of $429.
Granted that the multicore (CPU) score on the Tab is 2468 compared to 1405 for the iPad, but from what I gather the Affinity apps on the iPad depend much more heavily on the Metal performance (which would translate to OpenCL on the Android tablets) than on the CPU performance - and an iPad pro (granted a fair bit pricier) has a multicore CPU score of 4604 with a Metal score of 9149, neatly trouncing both of them on all counts.
 
When you look at the more "affordable" Android tablets (since your concern seems to be with the price of the iPad), the numbers look much worse for Android: the $330 Asus Zenpad 3S 10 has a multicore score of 762 and no OpenCL support at all apparently (as the score is marked "N/A"), while the $450 Galaxy Tab S4 shows a multicore score of 1489 and an OpenCL score of 1743.
In short, by the time you have something comparable to the performance of the iPad in the form of an Android tablet, you are actually paying more for the Android tablet than for the iPad.  If you are hoping for an Affinity version for Android in an attempt to save money compared to the iPad, you either won't be happy with the performance or will need to invest in a tablet that will wind up costing more than the iPad would have anyway.

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

https://forum.affinity.serif.com/index.php?/forum/52-feature-requests-suggestions/

 
If you included your reaction/request in this (old) thread, it would be obvious.
This way (new request without link to other thread) I have no chance of knowing, that you "read it".

This is a duplicate thread.  It has been requested before and Serif has already indicated this is not likely to happen in the near future.

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

If Serif wanted Publisher to happen it would have been released years ago.
Oh, wait...
 
You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize.  Just because it hasn't happened yet doesn't mean it never will.  Your priorities are just that - yours - they may not match those of other users, or of the developers.
 
A polygon tool was added to CorelDRAW after it had been around for over 6 years.
Adobe Illustrator was around for 6 years before it supported layers.  About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!).
It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one).
QuarkXPress was around for 9+ years before they started supporting bézier curves.
 
Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

Unfortunately, Apple's Time Machine can only go backwards.  They haven't solved the forward-in-time aspect of it yet (backing things up before they are created).

Unfortunately, Apple's Time Machine can only go backwards.  They haven't solved the forward-in-time aspect of it yet (backing things up before they are created).

Unfortunately, Apple's Time Machine can only go backwards.  They haven't solved the forward-in-time aspect of it yet (backing things up before they are created).

Unfortunately, Apple's Time Machine can only go backwards.  They haven't solved the forward-in-time aspect of it yet (backing things up before they are created).

@Matthias
I think the whole objective of color management for the designer is to preserve the fidelity of color appearance. That is to say that if a designer selects a particular orange for his artwork in one medium (ink, paint, computer monitor), he can expect the appearance of that orange to remain constant even as the artwork is translated from one medium to the next, or from one color space to the next.
It's incumbent on the designer to understand that the color gamuts of the various color spaces (e.g., Adobe RGB 1998, sRGB, U.S. Web Coated SWOP CMYK) are of different sizes and do not perfectly overlap, and to understand the difference between the relative values of RGB and CMYK numbers for describing color in specific RGB and CMYK color spaces (an orange that is described by the relative values R: 255 G: 128 B: 0 in the sRGB color space will appear differently in the much larger Adobe RGB 1998 color space), and the more fixed, absolute and universal values of CIE Lab, which describe the full spectrum of color that the human eye can perceive – independent of device or medium. 
Equally, our software tools should make it easier to understand the target color space in which we are working (for any particular document) and easier to pick and specify color with the confidence of knowing that the appearance of the color we've selected is right for our target color space and will be preserved on output.
That's the design challenge for the software designers and engineers.