fde101

InDesign has done this correctly from day 1.  All of its layers are what we are referring to as "Global Layers" - same as QuarkXPress.
The existing layers in the Affinity apps do not work this way and will not serve this purpose.
We cannot really ask to make this a "simple" option and change the behavior of the existing layers because it would substantially break existing functionality and documents.
Thus a new type of layer which we are calling "global layers" is needed in order to provide for this functionality.

Only Affinity software can import Affinity files.
People who are using Designer and VectorStyler in combination are generally transferring the data via the clipboard (copy/paste).

The one sticky point I have on this is arbitrarily treating multiple selected layers differently from a single selected layer.  If it is going to behave this way when multiple layers are selected, it should do so as well if a single layer is selected.  It could potentially be a different command (New Layer Containing Selected)?

When "Add Layer" is clicked, make it appear in the hierarchy next to a selected item. Also if multiple items are selected and if "Add Layer" is pressed, automatically put them inside the new layer.

The color pickers on the palettes sample the display color, not the color from the document - they must work that way as they can sample from anywhere on the screen, not just within the document or within the app - thus they always sample in RGB.
Given that the color picker tool only works within the document, you would think that would get it right and sample the actual underlying color, but sadly it does not.  I agree that this should be fixed for the color picker tool, but it would not be a sane behavior for the color pickers on the palettes.
All being said, as @walt.farrell suggested, this discussion should be moved to one of the various other existing threads on this subject, which is indeed different from what is being discussed in this thread.

This is unrelated to the current discussion, and would work better as a separate topic.

With the shape selected, use Rasterize to Mask, then drag the mask out on its own and use the magic wand in the Pixel persona to select the shape from the mask.  You can then delete the mask if you don't need to reselect it later.
Note this will also delete the original shape, so make a copy of it before rasterizing to the mask if you need to keep it.

@Frederiek, you might want to review this thread:
 
Depending on the exact nature of the halo, you might also try blurring the pixel layer being used as a mask (select it in the Layers panel, click the "fx" button along the bottom, select Gaussian Blur and make sure it is checked, make sure "Preserve Alpha" is turned OFF, adjust the Radius).
Another thing to try in some cases might be applying a light wrap (https://www.imaging-resource.com/news/2016/02/11/create-natural-looking-composite-images-using-light-wrapping-technique).
 

@MoonaticDestiny,
In case you didn't catch on yet, those color pickers can sample from anywhere on the screen, not just your document, and not just within the Affinity apps.
To make that possible, my guess is that the apps needed to set this up as a drag operation, since clicking on another app somewhere probably would not have been reported back to the Affinity app, and they probably don't have a good way to intercept it without jumping through sandbox/security hoops.
There is an actual color picker tool which does work the way you are requesting, but which only samples from within the document, and can't be used for the popup color pickers.

Hold two fingers on the canvas while resizing.

How many threads do we really need asking for a sorting feature for the layers panel?  There are a bunch of them already, such as:
 
 
No, it organizes them just like any other layers - in Z-order: whichever one is on top (not obvious with artboards which are separated from each other, more obvious with layers which overlap) is on top in the layers panel.  You can drag them to change the order, which also changes the Z-order on the page - that is, if rectangle B is above rectangle A, then dragging rectangle A above rectangle B would change the artwork itself.
It is natural that things which were most recently created would be on top in an art program, because that is the way that real-world artists tools work: when you paint on a canvas, you don't paint underneath the paint that you had already placed there.  You paint on top of it.  Your paint does not sort itself alphabetically on the canvas - what you paint on top, stays on top.
Because of the fact that the order of items on the panel is significant to the actual content of the artwork, a sorting feature for the layers panel would be a misfeature.
 
What could work is a separate "Layer Search" panel or window of some sort that would present the same list of layers, but allow you to sort and filter them in various ways.  This panel would have no effect on Z-order nor be tied to it, and so would be more appropriate for these types of queries.

There are really several ways you could go with this, and my suggested answers to the questions change based on what route is taken.
 
This one question I think has a consistent answer for all of these options:
 
When creating a new document from a template, the situation from the template is applied. When creating a new document from a preset or from scratch, a checkbox on the New Document window determines if a global layer is created automatically by default. When opening a document which precedes the existence of this feature, no global layers exist initially, but they can be added manually by the user.  
 
I will provide my suggested answers to the other questions based on three different options here.
 
OPTION 1
One option is my earlier proposal to have a drop-down on the layers panel to determine whether the page or master layers are currently displayed.  This should be simpler for users, but it makes importing existing documents more problematic.
 
With this option:
The layers on individual pages and applied masters representing the master pages disappear and the master page content is forced to either the top or bottom of the layer stack (whichever is closer).  
A new "Applied Masters" panel (or whatever it is called) provides the order in which the master pages are applied to the current page, listing the page as "Page 4" (or whatever) and giving the name of each master, allowing the masters and page content to be dragged in order and establishing what order within each global layer (when in use) the master page content appears in.  Individual master pages can also be removed from the page using the new panel.  If the page is selected in the new panel, then the layers panel shows the layers specific to the page under each global layer in the layers panel; otherwise, it shows the layers of the selected master underneath each global layer.
A drop-down list is added to the layers panel which matches the selection in the new Applied Masters panel - thus, what content is displayed in the layers panel.
This has the disadvantage of potentially changing the content of some documents due to forcing the master page content out of position.
 
Not for this option, at least not on its own.
 
Yes, when that master is selected in the drop-down list or in the Applied Masters panel.
 
No, though allowing master pages to inherit from other master pages could still be added and remain compatible with this approach.  For example, the Applied Masters panel could display them hierarchically in its list, allowing the inherited master from the selected master to be selected to have its layers displayed.
 
OPTION 2
The intriguing suggestion of a "Linked Spreads" option.
 
With this option:
Existing master pages get converted to "Linked Spreads" which have layers on each page exactly as current master pages do.  This maintains existing behavior and layer order for documents which predate the existence the new feature.
 
Yes, and potentially.
 
A new "Applied Masters" panel (or whatever it is called) provides the order in which the master pages are applied to the current page, listing the page as "Page 4" (or whatever) and giving the name of each master, allowing the masters and page content to be dragged in order and establishing what order within each global layer (when in use) the master page content appears in.  Individual master pages can also be removed from the page using the new panel.  If the page is selected in the new panel, then the layers panel shows the layers specific to the page under each global layer in the layers panel; otherwise, it shows the layers of the selected master underneath each global layer.
A drop-down list is added to the layers panel which matches the selection in the new Applied Masters panel - thus, what content is displayed in the layers panel.
 
No, though allowing master pages to inherit from other master pages could still be added and remain compatible with this approach.  For example, the Applied Masters panel could display them hierarchically in its list, allowing the inherited master from the selected master to be selected to have its layers displayed.
 
OPTION 3
Continue to show master pages as per-page layers underneath each global layer on a page they are applied to.
This has the disadvantage of slightly bloating the content of the layers panel and of potentially being the most confusing option for new users to come to grips with.
 
With this option:
Existing master pages remain as-is and behave as they do already.  The document behaves as if a single global layer already exists and contains all of the existing content, but it is hidden from the user.
 
No value with this option.
 
Yes, exactly as they are right now.  global layer would have the master page listed as a child layer, just as it is currently listed for the page as a whole.  The content of master page within that global layer would show up underneath the master page layer.  The master page layers cannot be dragged between global layers, but they can be arbitrarily re-ordered within the global layer amongst the per-page content.  
Removing any of the master page layers from underneath a global layer removes the master from the page, along with ALL of the master page layers of that master which would be shown underneath the global layers.
 
No.
 

This is definitely on the Mac:

(8^2)-1 = 63, that would be awfully small.  I think what you are looking for is (2^15) - 1.
The issue is that the message claims that the PNG format is limited to that size, but that is not true.  PNG supports up to (2^31) - 1; the limitation is imposed by the application NOT by the file format.

@Callum,
It appears that the same seemingly arbitrary restriction is also being imposed on the Mac version.
This is highly unfortunate, particularly as the message states that PNG limits the resolution to that which is clearly untrue.  PNG uses an unsigned 32-bit value to hold each of width and height, so it can support images over 4.2 million pixels high and wide.
The message should be changed to read something more like "PNG support by this application is limited to images with dimensions no greater than..."
Otherwise you are lying to the user.

Good catch, I had missed that comment.  Then yes, it is still over 2 million, but not the 4 million I had miscalculated as.  The point still stands.

So he is off by a multiple of 2 instead of a multiple of 65,000. Two billion is way bigger than 32 thousand.

Is that correct? 
From http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html: Under IHDR Image Header, Width and Height: Width and height give the image dimensions in pixels. They are 4-byte integers. Zero is an invalid value. The maximum for each is 231 -1  in order to accommodate languages that have difficulty with unsigned 4-byte values.
 
 

If the only thing people are adjusting is the font weight and possibly slant, then their primary advantage is in the web domain: if your site calls for a specific font to be downloaded, without this feature, you download a light version of the font, a normal-weight version of the font, a bold version of the font, an italic version of the font...  that chews up bandwidth and thus slows down the page load time, plus can be a problem for people on metered connections (where they might pay by the byte).  With a variable font, you download one font and have all of them, so it can reduce page load times (resulting in a faster site) and reduce the burden on those with limited download capacity.
For print, it can save disk space, but beyond that it allows for finer control of the parameters it offers.
However, the technology can allow the fonts to be customized in ways other than just weight and slant if the font is designed to allow for it.  The problem right now is that there are few apps taking them seriously enough for the font vendors to put much effort into offering other parameters that could have provided a much more rich set of ways to customize the shape of the fonts.  Currently the focus seems to be on weight and slant - but more would be possible if the technology were actually being taken seriously outside of its primary benefits for the web.
 
Here is a site with demos of a number of such fonts: https://v-fonts.com
A few of the fonts offer a "width" option to create narrow/wide flavorings.
At least one of them (Belarius Var) has an option to control serifs, allowing one font to morph between being a serif font and being a sans-serif font.
Another (Whirly Birdie & Whirlybats) has an "Animation" parameter that you can drag back and forth to animate the characters of the font (not useful for that purpose in print, but still shows some creativity and demonstrates that there is potential to do a lot more with this technology than most people currently seem to realize).
There are one or two others with some creative parameters as well.

If the only thing people are adjusting is the font weight and possibly slant, then their primary advantage is in the web domain: if your site calls for a specific font to be downloaded, without this feature, you download a light version of the font, a normal-weight version of the font, a bold version of the font, an italic version of the font...  that chews up bandwidth and thus slows down the page load time, plus can be a problem for people on metered connections (where they might pay by the byte).  With a variable font, you download one font and have all of them, so it can reduce page load times (resulting in a faster site) and reduce the burden on those with limited download capacity.
For print, it can save disk space, but beyond that it allows for finer control of the parameters it offers.
However, the technology can allow the fonts to be customized in ways other than just weight and slant if the font is designed to allow for it.  The problem right now is that there are few apps taking them seriously enough for the font vendors to put much effort into offering other parameters that could have provided a much more rich set of ways to customize the shape of the fonts.  Currently the focus seems to be on weight and slant - but more would be possible if the technology were actually being taken seriously outside of its primary benefits for the web.
 
Here is a site with demos of a number of such fonts: https://v-fonts.com
A few of the fonts offer a "width" option to create narrow/wide flavorings.
At least one of them (Belarius Var) has an option to control serifs, allowing one font to morph between being a serif font and being a sans-serif font.
Another (Whirly Birdie & Whirlybats) has an "Animation" parameter that you can drag back and forth to animate the characters of the font (not useful for that purpose in print, but still shows some creativity and demonstrates that there is potential to do a lot more with this technology than most people currently seem to realize).
There are one or two others with some creative parameters as well.

I agree, which is why I qualified that this only applies to the layers at the very top level, and only if using global layers - mostly because of Designer and Photo I don't believe they should automatically apply to all documents in the Affinity suite, and in particular they should not be available in documents based on artboards (such as those created in Designer), as they don't really have any benefit in such documents anyway.
 
Any one layer, yes.  A given master page needs to be able to put things on all of the global layers, but one (per-spread/page/master) layer/object may only be inside of one other layer (global or otherwise) or group.  That much is true already.
 
Agreed, for documents where global layers are used, as explained above.
 
That could be an alternative implementation to supporting documents with none at all, but it would be an internal detail for Serif to work out.
 
The problem with applying this universally is that the layer system structure is shared by Photo and Designer and global layers would be a pain in documents being worked on primarily in those tools, and provide no benefit when documents do not contain multiple pages, as is the case for documents created in those programs.  As a result, they need to be optional, or at least have the option of hiding them completely and using the current structure from a user perspective (possibly inside of a single default global layer which is invisible to the user) for documents which are intended primarily for those programs.  
Publisher would need to support working with such documents due to the "studio link" feature as well as due to the possibility of opening documents to work on which were previously created in Photo or Designer, while maintaining their structure so they can be sent back into those same programs.
However, I do agree that this functionality should be available for multi-page/spread Publisher documents, as an option the user can choose when to apply.

I tried this and as far as I can tell the interpolation of the gradient colors is being done in RGB regardless of the color space used to set the gradient stops.

I tried this and as far as I can tell the interpolation of the gradient colors is being done in RGB regardless of the color space used to set the gradient stops.

I tried this and as far as I can tell the interpolation of the gradient colors is being done in RGB regardless of the color space used to set the gradient stops.

In existing professional DTP applications such as QuarkXPress and InDesign, ALL layers are global layers, with any per-spread or per-master content being nested within them.  This is how it has been for several decades now and I have never seen complaints by their users that they do not have the option of limiting a given layer to a particular page.  That is not a description of how it needs to be in the Affinity apps, it is the reality of what already exists in other apps which professionals have been using for a long time, and it works.
As to whether or not the Affinity apps should behave that way, that may be an open question, but consider what could happen if they do not.
Assume there are three global layers, Front, Middle and Back.  As these are global, they appear on every spread and every master.
Now on a single spread of the document, call it spread 2, you add a spread-specific layer between Middle and Back, I will call it Local for purposes of this example.
Now we have spread 1 with layers Front, Middle and Back, and spread 2 with layers Front, Middle, Local and Back.
An important point possibly not mentioned until now is that the ordering of global layers is also shared among all spreads (at least, in existing apps).
What happens if I am working on spread 1 and decide to move layer Middle behind layer Back - what happens to Local on spread 2?  Does it move along with Middle, presumably because it was meant to contain content that should be behind the layer you are moving, or does it stay between Front and Back, presumably because it is meant to contain content that was intended to be in front of Back?  The movement of the global layer from spread 1 is ambiguous regarding the content of the layer on spread 2, because it is not visible in the layers panel and there is no way for the user to express that intent.
Let's assume for a moment that the software were implemented this way and the Local layer remained in front of Back, causing spread 2 to contain Front, Local, Back, Middle.
Now the user decided that Middle should have been where it was to begin with and moves it back.  On spread 1, the user only sees Front, Back, Middle, but for spread 2, the software need to decide if Middle is being moved before Back or after Front - in other words, it is again ambiguous as if the layer is being moved before Back, then you could wind up with Front, Local, Middle, Back.  Because the user has been working on spread 1, it might go unnoticed at this point that by manually "undoing" the move of Middle behind Back, the Local layer on spread 2 has in effect migrated from being behind Middle, to being in front of Middle.
Multiply this confusion across hundreds of spreads each of which may have "local" layers with different intentions, and you might start to realize why this is a bad idea - seemingly simple manipulations of the layer stack could wreak havoc on the structure of the rest of the document, and it would go unnoticed while you were focusing on just one place.
One way to resolve this would be to have the order of global layers independent for each spread - then if you wanted to move Middle behind Back it would only impact the spread you are on, but what happens when you actually WANT the layer to move on all spreads?  If you have hundreds of spreads, you need to go through and make that change on every one of them (and on the masters), which reduces the benefits of having used global layers in the first place.
These same issues occur for layers which are shared among some spreads but which are not present on all of them - the same issues would occur.
If you want a mix of top-level layers being both global and local (and possibly shared among some but not all spreads), this is the sort of problem that the intended behavior needs to be defined for.  Something needs to give at some level - there needs to be compromise of some sort, which is largely why I think @TonyB started asking those questions to begin with - to determine what kind of compromises people are willing to live with.
 
Consider just three of the many possibilities here, just with the points I raised in this post:
All top-level layers are global if any global layers are used, and the order of layers is shared among all spreads and masters.  In this case, there is no ambiguity when re-ordering layers, and document-wide changes can be made quickly and easily.  On the downside, a few of the global layers might not be used on every spread, so there might be a handful of extra layers cluttering the interface for the most complex documents. Possible improvement: a toggle is added to the layers panel to hide global layers which have no content on the specific spread or master, except when moving global layers.  This reduces the clutter under normal conditions, but needs to be turned off when first adding content to one of the hidden layers; making them visible when re-ordering the layers helps to eliminate the ambiguity of what to do with the others, but also means that the place you are dragging to in the layers panel becomes a moving target compared to when you started the dragging action. Top-level layers may be a mix of global, shared (subset of spreads) and local (per-spread) layers, including individual object layers; the order of global layers is shared among all spreads and masters, and the order of shared layers is shared among those spreads which contain them.  In this case, the number of irrelevant layers which appears in the layers panel is reduced, but moving layers which are global or shared can have unexpected consequences for other spreads of the document which may not be immediately noticed by the user. Top-level layers may be a mix of global, shared (subset of spreads) and local (per-spread) layers, including individual object layers; the order of global and shared layers is unique to each spread and master.  In this case, the number of irrelevant layers which appears in the layers panel is reduced, and moving any top-level layers on one spread will not impact other spreads at all.  To make changes to the layering structure of the contents of different global layers throughout the document, the layers must be manually re-ordered separately for each spread, even if there are hundreds of spreads. The need to manually re-order layers across many spreads can be alleviated by a menu command that opens a dialog box to express the exact operation desired.  This could allow specification of which layer(s) to move, where to place them (after layer X, before layer X, at the bottom of the layer stack, at the top of the layer stack, etc.), and which spreads to include in the change.  However, this would still be more work than simply having them all share a common layer order to begin with, and still cannot accurately express every possible scenario when dealing with layers that are not present on all spreads.  
Consider which of these (or some other behavior) would be most appropriate for your work, then try to consider people working on different types of projects, and realize that the one you pick will still cause problems for someone else.
My argument is that the well-defined behavior of all top-level layers being global and having a shared order among all spreads and masters, something which already exists in the wild and is well-understood in other apps, is the least problematic solution of any I personally can think of for the greatest range of users with the widest assortment of projects.  By all means, discuss other options if I missed something (as I am quite sure that I have).

For those of you who haven't seen this before, it might be easier to show you - this is how it works in QuarkXPress.  The layers in QuarkXPress are the equivalent of what we are requesting as global layers, and the objects on the spread (which are not considered layers in QuarkXPress) are listed underneath each layer (all objects are on layers, and all layers are global); additionally, if you toggle the visibility of a layer it is toggled across all pages (yes, I goofed the first time and toggled the object itself instead of the layer then realized what I did and went back and did it correctly):
 

Screen Recording 2021-11-22 at 9.28.17 PM.mov