fde101

Entire applications (ex. Publisher) have been added in point releases (there was no Publisher 1.0) so I'm not sure that this holds.
Even ignoring that, major features have been added (artboards and the appearance panel in Designer, astrophotography stacks and live projection in Photo, just to name a few) in "point releases" already.

Hi @YAN 焱,
Thanks for your report! I can confirm this is a known issue which occurs due to the difference in size between the 2 objects.
I'll be sure to 'bump' the development log with your report now.
Thanks for pointing this out, I've moved the thread to the correct location

Absolutely, and I believe it should.  Sadly, it does not.  It rasterizes the mask layer back into a mask layer, which is not even remotely helpful.

When you paste copied data into Photo it becomes a new layer, it doesn't paste into an existing layer, so that one piece of this at least is consistent and intuitive.
However, it seems to be just about impossible to merge two mask layers.  That should definitely be addressed.
It is also a pain to convert a mask layer to a pixel layer to make it easier to manipulate.  So far the only way I see to do that is to fill a new pixel layer with white, move the mask to be a mask of that layer, and rasterize the layer to apply the mask to it.  Once the mask becomes a pixel layer it can be merged with other layers and used as a mask directly (without needing to convert it back to a mask layer).
This is one of the reasons I generally don't use mask layers.  A pixel layer is much easier to work with and can do the same job without the hassle.

Just a guess, but probably to squeeze more onto the context toolbar which frequently doesn't have enough screen real-estate for people working on laptops.  That said, the tools they have done this with so far are among those with much less content there, so it does seem a bit strange.
 
Agreed, why not just "+" and "-" icons?  Or the ones you presented would be fine.

This is suboptimal.  The more correct way is to "like" the post with the request.
The "+1" posts needlessly waste people's time reading excess replies and the "votes" are mostly meaningless anyway so you are more likely to annoy people than to get any additional traction with "+1" posts.

The separate instances of the Affinity software would need to be able to coordinate with each other across the internet to avoid writing to the same places in the same file at the same time, corrupting it in the process.
If a document is modified on two systems which are not connected to the internet at the time they are working on the document, then a sensible means of merging the changes between the two editors may be required - and that would require support on the part of the underlying "cloud drive" provider to avoid having it throw out one of them before the software has a chance to see the changes and do something with them.
If changes are made to the document on one computer, the others would need to become aware of those changes having taken place in order to apply them locally.
If two designers try to modify the same thing at the same time in two different ways, there needs to be a policy of some sort to determine which change "wins".  This also needs to account for things like user A deleting a group just before user B adds a new layer to the group, then when trying to sync the changes B could not be added to the group that didn't exist at the time it was being added...
As the document format can track undo history, should the "Undo" command on one computer undo changes that were just made by a different user on a different computer?  If not, how should the undo history be differentiated in the document?  When opening the document within the Affinity software, how does the software know which of potentially multiple undo histories should be presented to the user?  (When someone tries to answer that the undo history for the same user should be used, consider that the same user might have opened the document on two different computers and be working on it in multiple places at the same time...)
Just for starters...

I have no use for that either.  Then again I rarely use the Info panel at all so I don't think I ever really even noticed it there.
 
For this to be a solved problem it would first need to be a problem.  Why do you need to constantly see that information?  What practical benefit does it have?  If you create the image from scratch you can simply create it at the size you are going to need.  If you start with something arbitrary just switch to the view (pan) tool or the crop tool and it shows up in the context toolbar, quick and easy.  Crop to the size you need and leave it there.
I'm not saying you don't have a use case for needing to quickly reference this information, as there certainly are times when you need to know this, but just hit "H" on the keyboard for the view tool and it is right there.  What use is it to display the resolution of the entire document when you are drawing with a pen or pencil, or applying a filter that impacts the entire area (or even just a selected layer)?

SQL is a domain-specific language that does not really belong in a comparison with the others.  It is like comparing the popularity of apples, oranges and Japanese.  That alone likely skews the results to the point of being less meaningful than a proper comparison.
Ignoring that I do find it to be a sad reflection on the state of our culture that so many programmers today tend to favor some of the worst programming languages in existence that none of the more reasonable ones (except SQL which again doesn't really fit with the others) even make it into the lists.  People are in so much of a hurry to produce fast sloppy coding with cryptic syntax that no one is taking the time to produce solid, readable code.

Creation/update of global colors, scanning (available on the Mac version only - not likely relevant to the iPad version?), the ability to hide the pixel selection without actually deselecting, astrophotography stacks, Edit in Designer (might not be possible on the iPad due to OS restrictions / sandboxing?), ...

And HTML/CSS should not be there either. Doesn't belong at all. 

Good advice, as always, but this thread was created in March 2020 and the OP hasn’t visited these forums since then!

True. However, in my experience some changes are not really saved until you close the application. If you make some changes, and then the application crashes, the changes can be lost. Therefore it might be safer to relaunch the application, to make sure the changes are really saved.

Pull quotes in some cases maybe?
I agree that I can't think of too many legitimate use cases for that.
 
It needs to be more general than that.  Currently all process colors are part of a general color space and are converted when the color space changes.  Spot colors are there but not always straightforward to work with.
There should really be a mechanism to tag a color as a device color, making it independent of the conversion.  A user would set up a global color as they can now but check a checkbox somewhere in its definition that says "this is a device color, don't mess with it", and as long as it is CMYK going to a CMYK destination, or RGB going to an RGB destination, it won't be converted regardless of how the color spaces are set up.
This would be a straightforward way to cover registration (CMYK all are 100%), K-only black (K at 100%, others at 0%), and possibly other situations that could call for such a thing.

Pull quotes in some cases maybe?
I agree that I can't think of too many legitimate use cases for that.
 
It needs to be more general than that.  Currently all process colors are part of a general color space and are converted when the color space changes.  Spot colors are there but not always straightforward to work with.
There should really be a mechanism to tag a color as a device color, making it independent of the conversion.  A user would set up a global color as they can now but check a checkbox somewhere in its definition that says "this is a device color, don't mess with it", and as long as it is CMYK going to a CMYK destination, or RGB going to an RGB destination, it won't be converted regardless of how the color spaces are set up.
This would be a straightforward way to cover registration (CMYK all are 100%), K-only black (K at 100%, others at 0%), and possibly other situations that could call for such a thing.

This was requested for Publisher, not for Photo.
I agree it wouldn't make much sense to add this to Affinity Photo, but it does make a lot of sense for Affinity Publisher, and maybe even for Designer (though to a lesser degree).
QuarkXPress also offers this, and even Swift Publisher has this feature.

You are looking at two different things.
The "Colors" palette in the Affinity products is an application-level palette with a long list of pre-defined non-global colors, while the "Swatches" panel in InDesign is showing you colors which are defined in the document, thus being the equivalent of a document palette in the Affinity products.
In Publisher, click the hamburger menu in the upper-right corner of the Swatches panel and choose Add Document Palette.  This will create an empty swatches palette that you can then customize with the colors you need for that document.

I did watch most of it, granted I missed the bit at the end.
 
I am familiar with that behavior, but it is not what Serif chose to do with the Affinity suite.  I agree that would make more sense for display purposes except that it would not indicate the starting point for any operations you carry out from there.
 
Most other applications handle it differently than Serif chose to.  They are different, not wrong.
 
It is accurate as stated.
 
It does work correctly, it simply works at doing something different from what you are trying to accomplish.
 
The transform panel currently scales the sizes instead of setting them.  This is the key difference.  If you have one object which is 3 inches and another which is 4 inches, and 3 inches is displayed, changing it to 6 inches is asking the program to double the size - so the one which starts as 4 inches becomes 8 inches, not 6 inches.
It is clearly working as designed, but the design is contrary to the feature you are looking for.  I agree that what you want to do is currently missing, but not that what is there now is wrong.  It is a different feature.

If the objects had different sizes, what would be displayed?  Using the bounding box of the selection seems reasonable to me.
 
If the objects are arranged on the canvas and you need to fit them into a hole in a larger design then by entering new dimensions for the bounding box you are scaling them as a group so that the entire set of objects fits in the space available.
 
It is not misleading.  This option causes the individual selected objects to be transformed independently, but all of them at once.  In other words, if you scale around the center, then each individual object is scaled around its own center instead of the entire set of selected objects being scaled around the center of the bounding box.
 
It scales them proportionally.  If one of the objects is 1" and another is 2", then setting the 1" object to 0.5" results in the other becoming 1".  Thus when you set the circle that was 0.9" to 0.9", you were scaling by a factor of 1:1, so the other objects similarly kept their existing sizes.  This is consistent with what happens when you scale them using the mouse while Transform Objects Separately is enabled, so there is some logic behind that behavior, even though it may not be the behavior you are looking for.
Setting all selected objects to a matching size would be a nice feature to have, but I do agree that it seems to be missing at present.

If the objects had different sizes, what would be displayed?  Using the bounding box of the selection seems reasonable to me.
 
If the objects are arranged on the canvas and you need to fit them into a hole in a larger design then by entering new dimensions for the bounding box you are scaling them as a group so that the entire set of objects fits in the space available.
 
It is not misleading.  This option causes the individual selected objects to be transformed independently, but all of them at once.  In other words, if you scale around the center, then each individual object is scaled around its own center instead of the entire set of selected objects being scaled around the center of the bounding box.
 
It scales them proportionally.  If one of the objects is 1" and another is 2", then setting the 1" object to 0.5" results in the other becoming 1".  Thus when you set the circle that was 0.9" to 0.9", you were scaling by a factor of 1:1, so the other objects similarly kept their existing sizes.  This is consistent with what happens when you scale them using the mouse while Transform Objects Separately is enabled, so there is some logic behind that behavior, even though it may not be the behavior you are looking for.
Setting all selected objects to a matching size would be a nice feature to have, but I do agree that it seems to be missing at present.

It's not always that straightforward of a conversion.  For example, on Windows you can switch among open windows using Alt+Tab, but on the Mac the closest equivalent is to switch among open applications using Command+Tab (not Option+Tab).
In Windows you can close a window / exit an application using Alt+F4 but on the Mac it is Command+Q (for Quit).

A "zoom slider" for the page thumbnails would obviously be better.

True, but if the series of actions performed by the app are sufficiently unusual that other apps do not commonly perform the specific steps in the specific sequence needed to trigger said bug then it may explain why it looks like the app is causing the problem.  The bug should be fixed in the OS either way if this is happening.
It may also be possible that this could be caused by a driver (or possibly a system extension?) in use by the WindowServer.

I've actually suggested the tags concept before, over a year ago:
 
As I explained in that post, however, tags are not a true replacement for global layers, mostly because of the lack of interaction with master pages.
The problem is that with global layers and master pages, you do want to be able to establish parts of master pages to sit on top of other document content and parts to be on the bottom.  Global layers (as implemented in other programs) allow for that, but the tag system suggested here does not provide a clear means by which to establish that.  It is by nature independent of ordering.
The "color tags" come part way.  They have a fixed finite number (rather than being named and allowing for further expansion), they are limited to one per layer, and as far as I can tell there is currently no global visibility or lock toggle for them.  Those things at least should be addressed.
I think there are use cases for both tags and global layers, and they each have advantages over the other, with neither one really replacing the other.
As I explained previously, the catch is that there is no clear way to import documents from the current system into one with a strict global layer system due to the arbitrary layer ordering that is currently possible with master pages.

Something to consider is that such formats generally result in larger file sizes and take longer to read, write and particularly update.
The current Affinity format was optimized for speed, and it is indeed reasonably fast to save a file, particularly after the first time when saving incremental changes.
For purpose of comparison, try setting the option in Photo to let it save over PSD files when they are opened, then compare the speed of saving a complex document to a PSD file as opposed to a native Affinity file - the PSD file is much slower.
Saving to a human-readable format like this is very likely to be much worse.
 
While the option of using a human-readable format for interchange and external manipulation purposes would certainly be welcome, I don't believe it should ever become the default format for these programs.  Rather it should be an option as an exported format (Affinity Interchange Format or whatever) and serve a role similar to that of IDML in the InDesign world rather than being a replacement for the existing native format.
 
 
Actually, the more I am thinking about this, there may be some value in borrowing a page from (gasp) Microsoft of all companies, by looking at the way they structured their current Office file formats (DOCX, XLSX, etc.).  These are actually zip files containing both a series of XML files and various other resources.  While the specific packaging format they use is kind of silly and totally unnecessary, there could still be some benefit from the more general concept of using a zip file with a different extension, containing a series of other files.
This would allow raster data to remain in a binary format (as a PNG file for each pixel layer and for previews of linked images for example) while providing a more human-readable format (JSON is usually more efficient than XML) for general layer settings, color palettes and the like, in a manageable and extensible form, and the zip wrapper would allow for compression of the human-readable part of the data to help reduce file sizes.
While this would still be less efficient than the current native Affinity format when updating existing files, it might still be a bit better than using a simple entirely human-readable format when one of the more common functions would be to store raster image data, which stores with very poor efficiency in such formats.
 
As an example, there might be a "layers.json" file representing the layers of the document:
[     {         "type": "rectangle", "top": 5, "left": 10, "bottom": 100, "right": 260,         "opacity": 0.5, "fill": { "type": "global", "palette": "Document", "index": 5 } }, { "type": "pixel", "locked": true, "name": "Background", "source": "pix00001.png" } ]  
With other JSON files representing the color palettes, general document settings, etc.  The content of text frames would probably be better stored in some XML or possibly RTF format, which could be referenced from the JSON file in much the same manner as images in pixel or image layers...