fde101

On the Mac you can already get very close to this using the Stationery Pad feature of the OS as described here: One current limitation (as @Old Bruce pointed out in that thread) is that it currently works by duplicating the document and keeping the copy in the same place as the template. With many current MacOS apps you can then easily rename and move the document to a more appropriate location by using options that appear when clicking on its title in the title bar, but the Affinity apps are currently a bit behind the curve in supporting this now-common user interface feature on the Mac... To my knowledge there is no Windoze equivalent to this feature.

Whoa, go back and read again: the Serif team has all but confirmed that they do intend to implement "global layers" as we have taken to calling them in some future version of Publisher. What I was responding to was the notion that someone seemed to be suggesting that it ONLY have global layers, and that is what will not happen - the program will ultimately need to support BOTH types in some manner.

It is extremely unlikely that this will ever make its way into Photo as that program is not really engineered for the construction of multi-page documents. Designer doesn't build multi-page documents either, at least not yet, but there were hints that it might do so later on, so that is at least a possibility, though realistically I would not anticipate a data merge tool except in Publisher.

Ultimately these shapes are still formed from bezier paths behind the scenes, so the tool could simply generate the intermediate shapes by substituting a "converted to curves" version of the endpoints for its calculations and using its arbitrary-path algorithm in cases like this. The team from Serif has already hinted that they developed this feature with future expansion in mind. Evidently we will eventually be able to customize the arrowhead shapes, for example.

What about losing a week's hard work? This should make no difference.

Was it selected for one curve and not for another that was being joined? While this demo is obviously a bit extreme I could see that as causing some confusion as well since it is a per-object property right now. Ultimately I would prefer that stroke width and the scale with object property be configurable per node of a curve rather than limited to being set for the object as a whole.

My comment on this was not specifically related to the rasterization of the layer, but rather to the general behavior of the various windows being referenced in the OP, which are not dialog boxes but property windows or similar. The Affinity applications DO give you the option to disable the automatic rasterization, via the Assistant options. The one thing that is a little strange is that they are enabled by default, but for this type of program I personally think that is reasonable. These are not exactly common consumer applications but are intended for professional users who need to take a bit of time to understand their various quirks regardless, and this is a sensible one that saves you the time of doing this manually when performing those actions that require them. You wouldn't expect a paintbrush tool to ask for confirmation before making a brush stroke that would wipe out the content underneath that stroke...

That takes me back a bit, as there was previously a collection of utilities for older Windows versions having that same name. Looks like they are starting over with this one though. Tiling window managers have been around for UNIX platforms for a long time now (Wikipedia lists several of them: https://en.wikipedia.org/wiki/Tiling_window_manager). Interesting to see them coming out with one for Windoze. This isn't the same thing Haiku is doing, it is a different approach, but interesting nevertheless.

The windows you are pointing to are not dialog boxes asking for details before doing something. They are properties windows allowing you to adjust things in real-time, where those changes are applied immediately to the document. There is nothing to cancel here - you are working with the document in real-time. You would need to undo those changes (Command+Z), not cancel them. This is VERY common in modern application design so it is something you should probably get used to. It is actually a good thing in many ways. Locking a layer in the Affinity products only locks its position, it doesn't otherwise prevent it from being modified. This has come up several times in various threads on the forums and is expected behavior based on how that tool is defined. As @Pšenda suggested, you can disable the automatic rasterization of layers for many situations such as this using the assistant options if you don't like it. Undo works here also if you catch it when it happens. I could see having ESC close the window as being a possible improvement (assuming the window has the focus), but again, there is no "command" to cancel here. The window is a properties window for the adjustment layer that was added, it is not a dialog box prompting for information before a command can be applied. True, but it can be quite convenient if you have a large number of layers which get scrolled out of view, or if you have multiple such adjustment layers in place and don't want to take the time to figure out which one to delete when the properties window for it is right there in front of you. The Character panel is a studio panel which can be docked along with the other studio panels on the edges of the window (drag the tab). Using ESC to close this wouldn't make any sense as it is not actually a "window" in the normal sense but more like a variation on the concept of a toolbar. No, pressing ESC does not apply the changes you make in preferences (which are not system preferences but application preferences, btw...), the changes were applied as soon as you made them (except the ones that require the application to be restarted first). Pressing ESC simply closed the window. None of the things you are reporting here are bugs or unexpected behaviors.

Way back at the dawn of computers there were big expensive monolithic systems that people had to schedule time to use because they were so expensive to buy and maintain that there was no way for everyone to have one at their desk. Later terminals would allow multiple users to access the computer seemingly at the same time, but sharing the processing resources of one big computer. Centralized computing. Then came micro-computers and suddenly users might have their own computer sitting at their desk. Distributed computing. Then came the whole client-server thing where major processing was pushed to a server but each user accessed it through a personal computer much like they would have used terminals to access a mainframe in the past. Centralized computing. Then came peer-to-peer solutions which shared data among separate computers without the need for a centralized server. Distributed computing. Now we have the whole "cloud" thing going on where big companies are farming out major computing resources and users access them remotely from their various "devices". Centralized computing. The computing industry in general seems to go through cycles where what was unpopular in one generation becomes the "in" thing in the next. As people start to realize the limitations of what is currently "popular" they try something else and with the effect of the latest buzzword things swing so far in that direction that it needs to correct itself and things get carried back in the other direction. There is nothing wrong with floating windows, and things that were designed in the 1980s are not inherently bad in the 2010s. Don't let yourself get suckered into the buzzwords that happen to be popular at the moment without understanding first that there are tradeoffs to all of it and what is popular at the moment might not be the best thing for your particular problem or situation. Most things do. I kind of like what the Haiku OS project is doing with their "Stack & Tile" functionality, for example... a definite step in the right direction as it provides the flexibility of a multi-window interface while still allowing for windows to be stuck together, even including windows from different applications if that helps with organizing how you are working...

It has always been like this when working with path objects (curves), which are the bread-and-butter objects for many workflows in which the shape objects may well be ignored completely. As it currently stands, the tool in Designer only applies to path objects, not to shapes. When you try to use it on a shape it gets converted to a path so that it is compatible with the tool. As I previously indicated, you can get the equivalent for rectangle shapes by using the node tool. Supporting the use of the corner tool directly on the shapes is a perfectly reasonable feature request, but the fact that it is not there now does not make the tool "destructive" - simply not supported for the type of object you are trying to work with, and as a convenience, if you try to apply the tool to an object that it is not supported for, Designer is converting the object into a type that is. That conversion may be thought of as "destructive" in the sense that you lose access to the other control points of the shape (while gaining the ability to adjust the individual nodes using the node tool instead), but the tool itself is not unless you ask it to be. Considering all of the options they have already placed into the shapes, I am forced to disagree. I think they offer quite a lot in this category (control points on shapes, adjustment layers, etc.) and have set themselves up well to add even more in future releases, but pushing too far in this direction would actually reduce the flexibility of the product. Sometimes you just need a hammer instead of a screwdriver... That said, what you are effectively asking for here is not impossible to do without losing the existing flexibility, either by adding additional control points to the shapes in the way that they are handled now using the node tool or by supporting the corner tool directly on shapes, but it's not there yet.

The Mac versions have been fairly stable for me also.

True, but in a large number of cases it may only have one, so the shortcut could be effective only when on a page or master which has a single master applied to it, for example (and just beep if there is more than one and the user hasn't selected one).

Unlikely as the development libraries and languages used between the two platforms are quite distinct.

No, I understand now what he is complaining about, and it has always been this way. The corner tool doesn't work on "smart" shapes, only on paths. If you try to apply it to a shape object, it does convert the shape to a path before you can use the tool. I don't really consider this "destructive" - it is simply a helpful mechanism that turns the shape into something the tool can actually work with. @deeds, note that if you are working with rectangles, you don't need to use the corner tool to get the same effect - you can set the corner type for each corner (either all of them at once or separate corners individually) using the context toolbar while using the node tool with the shape selected. This keeps it as a shape, but it only works for rectangles. I'm not sure how that tool would even begin to work with some of the other shapes as not all of them have sharp edges anyway. For those that do, what are you trying to do with them that still keeps them as that shape? For the kind of adjustments I can think of offhand where you would use that tool on one of them it wouldn't really be the original type of shape any longer (unless you can already make the adjustment using the properties of the shape, using the node tool), so I'm at a loss as to why you seem to think it is unreasonable that this would convert to curves?

With an application like this one, I would argue that a list should be pointless. If a function exists in the application it should be possible to assign a shortcut to it.

Shouldn't this be in the bug reports section?

Where are you seeing this?

Hi @DavidJB, welcome to the forums! I don't believe this can be changed yet.

It's not just rotation and presets, though individual-character-transform controls (at least scaling and rotation, preferably shear as well) in artistic text (on or off a path) would definitely be a most welcome addition. If you pay close attention to the screenshot from the other program in the original post, the letters are actually reshaped to the path - the lines from that "E" are reshaped somewhat to follow the path while the left edge of it is very nearly vertical. That might be more of a shearing transform but if time is going to be spent on trying to automate such things I would suggest that the ability to let the characters follow the curvature of the path be enabled across their width - consider a few options that can be set for text on a path, probably applied after any manual character transforms that might be applied (if and when implemented): Should the characters be rotated to follow the path? No rotation (all characters remain upright relative to the overall transform of the entire object) Rotate the entire character based on the normal of the path at the left edge, center or right edge of the individual character Rotate all characters to a set angle regardless of the flow of the path Rotate all characters based on distance from the center point of the text, ignoring the flow of the path (if the text is essentially horizontal, this would cause the character in the middle to be upright, with increased rotation when moving away from that in either direction) Apply "random" rotation to each character Should the characters be reshaped to follow the path? No reshaping Shear the character based on the overall slope of the path (if the text is essentially horizontal, this would apply a vertical shear so that if the bottom of the character is a straight line, the slope of that line matches the slope of a line connecting the points of the path which are at the left and right edges of the character's position on the path) Warp the character based on the slope of the path (if the text is essentially horizontal and the path underneath the character is curved, this would apply that curve throughout the height of the character, so that an "E" for example would have all three of its horizontal components matching the curvature of the path underneath it). Presets for text-on-a-path would not be a horrible thing, but I would argue that these are best handled as assets in the Affinity world (drag out an asset which is set up the way you want it and modify the text from the asset), and that should be possible already.

Same thing with an asset would be nice... and if replacing something with an asset that has an unpopulated text or picture frame, if the thing being replaced has one that is populated, the content should be retained in the replacement object.

Doesn't that kind of defeat the entire point of it being a navigator? I would think that should be a separate "preview" panel.

The crowd is certainly persistent...

The "HSL to RGB alternative" provides for conversion in one direction without needing that, but I agree that formulas going the other way are not presented which do not require that. Built-in functions to convert the colors would be helpful, though even simple conditional functions of some form would make this possible. For example, a function like if(a, b, lt, eq, gt) which returns lt if a < b, eq if a = b, or gt if a > b - even that much would be enough to make this work, if not the most convenient. Maybe as an alternative form, shortening it by one parameter and calling as if(a, b, eq, ne) would return eq if a = b and ne otherwise...

I agree with @Ray S. that a LUT is the general solution for this as it covers more adjustments than simply curves and they can cross over between applications. There are even applications out there now whose entire function is to generate LUTs that can then be used in other applications, and there are numerous sites with free and for-sale libraries of them. The idea of having general support for export/import of adjustment settings is not a bad one, but if the idea is to build a library of looks that can be replicated across images, LUTs are simply a better solution for that.