fde101

Extrusion in this context is a fairly well-understood function. The application makes a duplicate of the object and connects the duplicate to the original at each node around its edges, forming shapes between those connected nodes which are then filled with an indicated color, pattern, gradient, etc. Not to be confused with the extruders which are components of 3D printers.

More directly: https://www.libraw.org/node/2710

This has come up before several times, and Serif has consistently indicated they have no intention of merging the apps.

The only way you could do that would be to add a new pixel layer to contain the results of the inpainting process. This would complicate the tool since you would need to have both the source image layer and the destination pixel layer identified to it; if multiple layers may be selected, how does the tool know if it is to react independently on both of them, or split their purpose in this way? If the tool just creates the output layer when the selected source layer is an image layer, would it create new ones for every stroke?

It adds clutter, provides no new functionality, and exchanges one potential cause of newbie confusion for another: specifically, why we have two icons that open the same panel when all of the other panels only have one. I am not convinced this "issue" you keep referring to exists, but would it not be a better solution to simply show both colors in one icon, making it look more like the color indicator from the toolbar on the desktop version? Or perhaps more like this? I can scroll if needed, and I already do need to scroll the tools on the left. There is simply no need to clutter the list with a duplicate icon that has nothing new to offer. The undo and redo buttons can be turned off in preferences (as they are on mine). You can get the same undo functionality by tapping with two fingers, and you can also access both features more directly simply by tapping on entries in the History panel. The help button (in my opinion) is OK where it is, but it could easily be moved to the hamburger menu as well.

On my iPad there is not enough room in the bar along the right to add that additional indicator without forcing the set of icons to be scrolled. We already have users complaining that having icons that far down along the sides is disrupting their workflows because they don't have room to rest their hands without activating features from those icons in the corners, and while I consider that a user adaptation concern and don't necessarily agree with removing the icons there, I don't think adding another one simply to avoid confusion by users who will learn the current system in time is going to be a popular recommendation among those with smaller or more normal sized iPad displays.

For whatever it might be worth, I was looking at the idea of combining those two panels. I do not agree at a conceptual level that those panels somehow "belong" together, but there are some practical limitations of the way that the UI has been set up on the iPad that makes me inclined to agree with the overall notion of merging those panels on the iPad version - not on the desktop version - of the software, unless more meaningful changes to the UI render that unnecessary. The problem becomes that unless you have the larger iPad Pro displays (not all of us do) you will wind up scrolling to access most of the panels after they are merged. Your design omits a few critical components of the panels to give the illusion that they will somehow fit together onto one display, but that is not quite the case. I do think it could be done in a reasonable way, but additional controls would need to be represented somehow, probably by adding tabs or popups in various places. That would unfortunately mean extra taps/"clicks" to access those features, potentially negating the benefit of merging the panels, depending on the use cases of individual users. There may be a happy medium here somewhere, but this would require a bit more careful planning to work it out.

note that as an alternative you can use the [ and ] keys on the keyboard depending on the tool you have selected (and those keys can be customized if needed)

Strange or not, I rather like some of the things I can accomplish with it, so I'm against any proposal that removes that ability.

Noise is treated as a property of color in the Affinity products because it is set individually for each stop of a gradient, allowing the noise to be graduated between the stops. That would not be possible if it were moved to the FX panel which does not tie its properties to gradient stops.

There was a time when displaying a splash screen was actually a violation of Apple's Human Interface Guidelines for the Mac. They seem to have relaxed this in more recent versions, but point being, their presence is not favored in modern application design. The Affinity apps load fast enough that the splash screen could easily be (and therefore should be) eliminated completely.

It wouldn't be unreasonable to create sections for things at that level, and those can have names.

This is already being developed, as per the pinned thread on "Scripting". In the meantime many types of barcodes can be done using special barcode fonts and there are 3rd-party tools that can be used for QR codes and the like.

I save even more space than that. Once of the first things I do after setting up Photo on a new computer or user account is to close that panel since I never use it. If you do find it useful for some reason, then I can see how that could save a bit of time on scrolling, but at the expense of time spent either memorizing the icons or waiting for tooltips to pop up telling you what each one is.

You might want to review these:

If you prefer to work that way, there are ways to do so. One example: Make sure you don't have any layers selected, then hit the Mask Layer button along the bottom of the Layers panel. Use a black brush (or other relevant tools) to paint onto that layer the area you want to effect (if at 100% opacity you are asking for full effect and the area will turn transparent). After you have the desired area targeted, invert the mask layer (Command+I by default on the Mac - Layer->Invert) and only the targeted area will be visible. Deselect the mask layer, add the desired adjustment layer, drag it below the mask layer, and group the mask and adjustment layers together - you can then edit the adjustment layer and it will have an effect on the intended area. If you select the mask layer, you can continue to refine the area. If you add an additional adjustment layer to the group (keeping it below the mask layer) it will apply its effect to the same area as the existing one.

It is not wrong depending on the purpose of the brush stroke usage. Consider that the brushes can be used for painting on a mask and that allowing accumulation when you are trying to set an area of coverage can produce uneven results making the usage of the brushes much more difficult for that purpose - and I have no doubt that other examples exist. Photo is meant for photo manipulation first and foremost, and the current behavior impresses me as the most likely for that function, and is almost certainly the best default behavior for the application's primary function. What is being requested here (allowing the opacity to build without "lifting the brush") is more in line with painting software, which is a secondary function of Photo rather than its primary use case. While I agree that this would be a good option to have, it is not an ideal default behavior for this particular application, and should either be a property of the specific brush, or an option to toggle on and off (likely from the context toolbar) depending on the intended usage of the tool at that time. The reverse would be true for an application such as Painter or Krita whose primary function is painting.

Agreed there should be an option to allow opacity to build within a single stroke, at least for raster brushes. The current behavior is perfect for many use cases, but having this additional option would be a relatively simple way to expand on the application's potential. It would only need a checkbox for the UI behind it...

Try it. If your selected layer is an empty pixel layer, then you can adjust the selection and only the empty pixel layer is impacted. If you then copy merged, it copies the combined data of the layers that are visible within the selection - as the empty pixel layer is empty (and 100% transparent) it has no effect on what you wind up copying. The method @Return pointed out also seems to work (assuming default shortcut keys):

Interesting... I was just playing with this a bit more and those handles only show up if there is a pixel layer selected. The selected layer does not need to intersect with the selection - you could have an arbitrary pixel layer completely off to the side and having nothing to do with the selection and it will otherwise behave as I described it - so I'm not sure why that would be a requirement. I can get it that they might hide those if a non-pixel layer is selected, but with no layers selected, wouldn't it be better to display those handles and let the user manipulate the raster selection without impacting the underlying layers? A workaround for now is to create an empty pixel layer and select it. I don't think that should be necessary, though.

yes

If you have a raster selection, it puts handles on the selection that can be used to resize, rotate and shear it. If there are intersecting pixel layers selected their content is also affected, but you can prevent that by deselecting the layers and having only the raster selection when using the move tool to manipulate it. If true that is likely a bug and should be reported in the bug report section rather than here in the feature request section - but are you sure that you are accounting for the marquee itself possibly sitting on top of that pixel?

To adjust the marquee using handles after creating it, switch to the Move tool. Also. try Copy Merged (Command+Shift+C on the Mac) instead of just Copy.

Not quite exactly - this converts the end points to "sharp" ones, effectively deleting the control points, rather than adjusting the control points without removing them. It's a little thing, but it is a thing. It also doesn't provide for other functionality such as the bisection feature I listed.