fde101

While I see no problem with this request, out of curiosity, why would you find it useful?

"Document-Wide" and "Custom" should be replaced with tabs at the top of the panel for "Selected Note(s)" and "Document Settings". The choice of note type would be immediately underneath that. For "Document Settings" you would always see all properties, and they would always adjust the document-wide settings regardless of what note was selected. For "Selected Note(s)" there would be a checkbox "Use Document Settings" and the rest of the settings would be disabled when it is checked.

It would not be logical to do this in application preferences when you might want light-colored guides in a dark-colored document but dark-colored guides in a light-colored document. To borrow a paraphrase questionably attributed to a famous physicist, things should be made as simple as possible, but no simpler... If you want to avoid setting these repeatedly, the ideal solution is to set them in a template that you use to create new documents.

Multiply by a constant is basically the opacity setting of the layer on a normal blend mode, or alternatively an Exposure adjustment. Adding/subtracting a constant, I believe, is the Brightness control on a Brightness and Contrast adjustment. I think most of the others are already covered by the various blend modes? https://photoblogstop.com/photoshop/photoshop-blend-modes-explained

A parallel concept might be that of a style variant. We can already base styles on other styles: for example, if I have a base style named MyStyle, I might create another style which inherits from it and simply changes the text color to red, maybe MyRedStyle. Now consider having a "Style Variants" panel with a list of variant names and a "Default" or "[No Variant]" option already present as part of the document - names might be "Screen Display", "Printing", "Proofing", etc. - and being able to create a "Variant Style" as a child of either a paragraph or a character style, which rather than having a name of its own, would inherit the name of its parent but with one of the defined variants associated with it. When the user selects a variant name in the Style Variants panel, any styles that have a variant style as a child which are associated with that selected name, would have that variant substituted for the base style; any that do not would simply use the base style. This generalizes the concept and allows for quickly reformatting the text in the document for different purposes by making a selection in the variants panel.

The problem with this is that the grid is a per-document setting - you can have different grids selected in different documents - it is not an application property. The canonical solution for this in the Affinity products is to create a template with the grid set up the way you want it, then use that template when creating new documents. There is a problem, however, when working with Photo, in that many documents are created by "opening" a RAW file or other raster image file, which in effect creates a new Affinity Photo document and imports the image into a new layer of that document which is then named "Background". Currently there is no opportunity to access a grid which is stored in a template when "opening" raster images in this way, and I believe that is the problem which should actually be solved. Rather than a piecemeal solution for one property at a time (grid, etc.), I think the best way for this to work is to allow the user to specify a template of their choice to use when "opening" raster images or RAW files, perhaps with an option to use it (or a different one) when creating from a preset also (as this is something that is a bit more iffy). The user could then save a template with their desired grid settings, maybe a few adjustment layers for soft proofing (likely turned off but still set up and ready to go), and when they open a raster image, it would open a copy of the template, set the document size to match the image being opened, and import the raster image into a new layer on the bottom of the Layers panel. This would solve the problem for the grid, allow the user to rig custom adjustment layers to be ready to go for any new image they open, have custom document color swatches (even global ones) in place and ready to go, etc... and it should be fairly straightforward as all of the underlying mechanics to make it happen already exist in the application.

It is curious to me that you can't simply select the group and make the desired changes. You can, for example, select a group of shapes and choose a color to apply that color to all of the shapes in the group, so why could you not select a group of text objects and choose a text style, or a font, to apply it to all of the text objects in the group? That omission seems both inconsistent and unnecessary.

Yes, they are based on the symbols technology from Designer, but it kind of defeats the purpose for which master pages were intended. Master pages are to create uniformity among the individual pages of a document. You can misuse them in the way that you demonstrated here, due in part to their connection to the underlying symbol technology, but this purpose would be better served by switching to the Designer persona and using actual Symbols, or to the Photo persona and using Linked Layers, both of which are intended for what you are doing here. If you do not have Photo or Designer, then this usage of master pages could be a valid workaround, but it is not really their intended purpose. You are finding an alternate use case for them which is supported by an implementation detail. In a smaller document you could get away with this more easily: when you start working in longer documents such as books with hundreds of pages, intermixing this technique with the more genuine, intended function of master pages, I would think more likely to lead to confusion.

Even setting aside the ability to misuse master pages and treat them as if they were symbols, completely missing the point of why they exist in the first place (to create uniformity among pages and reduce the amount of work needed to create a long document with said uniformity), consider that you can have more than one master page (more usefully several different ones) assigned to a page. Placing them in the Layers panel allows you to alter the stacking order of the applied masters, not only in relation to each other, but also in relation to the objects on the page itself. It also provides a mechanism for removing a master page assignment (you can delete the layer). This ability to alter the stacking order is in part a workaround for the fact that there are no "global layers" (as have been discussed separately) but also presents possibilities of its own, though it is much less useful than having real global layers would be.

Just to point it out, the styles can also be selected using drop-down lists on both the context toolbar (when editing text) and on the Character and Paragraph studio panels. The drop-down lists do separate the Character and Paragraph styles from each other, so while it does mean one more click (to open the drop-down), using these might help to eliminate the scrolling. Or, you could use the Text Styles panel for the paragraph styles, and one of the drop-down lists for the Character styles (or vice-versa)...

But is the nearest ancestor Layer truly the current one, or is the topmost Layer which is an ancestor of the selected item the current one, or are all three layers current since they are all ancestors of the selected item? What if there are items selected on two different layers which are both at the top level? This is what I was trying to get at: the entire concept of the "current Layer" is somewhat ambiguous.

This is normal. It has only very rarely if ever been possible to open files from a newer version of the Affinity software with an older version. This is also explicitly called out on the page where you can sign up for the betas: https://affinity.serif.com/en-us/affinity-beta-program/

Rebelle offers this in their Pro version (I think their own implementation of it).

Where this is unlikely to be sufficient is in certain categories of workflows in which continuous export is being used to update resources used externally during the design process. For example, if using either Photo or Designer to work on images that are resources in a game engine, the continuous export feature could be used to export selected regions of the document constantly as they are edited. These exported images could then be picked up by the game development software when they change on disk, allowing for near-real-time preview in context in the external software while the editing is being done in the Affinity app. This is something that cannot currently be supported in Publisher due to lack of that persona... but at the same time, something that Publisher and StudioLink are unlikely to be very helpful with. I would think that working directly within Photo or Designer would probably be the better choice for those workflows anyway.

It kind of stands to reason that when there are no explicit layers in play then the page, artboard or document serves the role of the layer. The situation in which it becomes most confusing is the one in which you have nested layers. In this situation, there are three layers, and an argument could be made that all three of them are "current" since the red rectangle is selected and is on all three of those layers. Thus, is the blue rectangle on the "current layer" or not?

All of you are completely ignoring group styles, which fit neither and both categories. The filtering idea would need another button, and if you split the panel, you would need three of them, not just two. I think if cleverly implemented the filtering option is the better choice here, rather than splitting up the panels. However, I would argue that it would also be nice (not just for this one but for several of the panels) to be able to have more than one open. Thus you could open two text styles panels, and set a different filter on each of them, to give you a similar effect to having had the panels split. The Swatches panel is another candidate to allow more than one to be open - you could have one open to a document palette and another to an application palette for example. Multiple copies of the Assets panel could be opened to different categories...

What I was referring to by the "modern" approach can be seen, for example, in Digital Performer (a digital audio workstation), in which Shift+Spacebar brings up a small window in which you can start typing to search through all of the tools, menu commands, etc., which are available in the program, and see their shortcuts, what they are, as well as triggering them right from the menu:

The classic way to handle this is to have a "Tools" menu in the menu bar which mimics the toolbar but lists the tools by name instead of using icons. A more modern approach is a searchable pop-up menu that appears with one keyboard shortcut you would learn, which you could then start typing the name of a tool or menu command in order to find and switch to / execute it.

Resolve isn't really a replacement for After Effects so much as for most of the other video-related apps offered by Adobe - Premiere for example - but it does have an integrated version of Fusion which is good for smaller tasks. That said, Fusion and Resolve Studio both include licenses for each other. If you buy either one, you have access to both. There is a free version of Fusion which is built-in to the free version of Resolve and can be fine to get a feel for it, but there are a few limitations to working with the version which is integrated into Resolve.

Only once per combination of settings. You could simply cache versions with each variant of those settings the first time the settings are encountered, then switch to the appropriate cached version when the settings are changed again.

Not sure why this keeps coming up, but not necessarily the best use of Serif's time when they already seem to be stretched fairly thin as it is; if you are looking for motion graphics capabilities check out programs like Apple Motion or HitFilm; maybe add something like SynFig Studio for certain specific use cases. For compositing work, take a look at Fusion from BlackMagic Design, or at Natron. Point being there are already several solid options out there to replace After Effects, including a few free ones.

If you are using the built-in Serif-provided RAW engine, support largely follows what is released by libraw, and they supposedly added support for this camera in version 0.21: https://www.libraw.org/news/libraw-0-21-release That release is long after development of Photo v1 ended, so you won't be getting support in v1, as others have mentioned. I don't know if 0.21 has made it into the v2 series yet but it should soon if it has not already. What that does not indicate is whether or not this specific format of the camera was added as supported. Information about how to interpret those files is evidently available: https://github.com/darktable-org/darktable/issues/10556 It is not clear from what I am finding if even Apple's RAW engine supports those files either, otherwise you would have the option of using Apple's RAW engine instead of Serif's if you are on a Mac, and if macOS does support that format, then you could potentially use that even with v1.

If you are opening a document file (such as any native Affinity file) you should see an accurate representation of what was saved in that file. If there was a locked background layer when the file was saved, you should see one when you open it; if there was not, then it should not be there when you open it. When you "open" an image file which does not natively have a concept of layers by itself, the content of that file needs to go somewhere, meaning a layer needs to be created for it (Publisher is not actually opening the image file directly, but rather creating a new Publisher document and setting it to match the content of the image file; a Publisher document needs a layer to store that content). Traditionally (I believe originating from Photoshop), that layer is called "Background" and is locked to prevent the user from accidentally moving it out of position.

How would you simplify that without losing any functionality? Everything that is there exists for a reason and provides some benefit to some subset of the application's users. It actually appears that in spite of having added a few new options they have already simplified the Wireframe options a bit compared to 2.1.

There were originally two shapes, one green and one blue, that overlapped completely the same area. Both were cut up by the other (acting like cookie cutters to split each other up) and the blue one was deleted because it was underneath the green one. That is how I read it anyway.