Balakov

Wow. This is so cool. Thanks!

Great tool! Thanks.

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

Mind officially blown, thank you @Balakov
Stock Photoshop Gradients.zip

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

I spent the last weekend creating a tool to convert Adobe suite .grd gradient files to .afpalette files for use in the Affinity suite.
There are so many great resources for gradients out there but no easy way to get them into Affinity applications without a lot of manual labour.
The tool is hosted on GitHub (the Javascript code is available for the curious), but all processing is done in your browser. No files are uploaded anywhere.
https://mikestimpson.com/GrdToAfpalette/
There are a few limitation around colourspace (RGB only) and transparency (not supported), and I have not tested with a huge number of .grd files. It works for what I needed 🙂

Hi, I've just updated to Designer 1781 on Windows and my artboard backgrounds are now super bright. I run in dark mode with the artboard background grey level on the lower default setting, but it doesn't appear to have any effect. Moving the slider does nothing.
I've attached screenshots of 2.1.0.1781 vs. 2.04. This was working fine in previous beta builds.
Cheers, Mike.
2.1.0.1781

2.04

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features.
The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded.
An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists.
The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method.
Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features.
The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded.
An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists.
The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method.
Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

I was recently emailed back by one of the developers. Apparently, the MSIX versions of the apps can be a bit buggy, so they recommended me to download the .exe installer versions instead. I haven't been using designer as much recently, but in my small amount of work it appears to be better?
On the downloads page you have to scroll down and find this part:
And install it with those files instead! Hope it works better for everyone else. Of course i'll update this post if it isn't in fact helping.

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features.
The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded.
An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists.
The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method.
Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features.
The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded.
An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists.
The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method.
Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features.
The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded.
An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists.
The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method.
Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

I've been having this issue for years dating back to Designer V1 and the same issue has remained in V2. My job is making .NET Windows software so I've done some performance captures during the slowdown which hopefully might give the developers a bit more insight. I don't work with very heavy scenes, my normal workflow is to create a few scratchpad artboards, drop some reference images and then use the pen and shape tools to make my designs. I'm generally not using any advanced features.
The first perf capture is after about an hour or working. At this point clicking on objects is taking about 1 second to register and about the same time to switch tools. Memory use is around 3GB on a 32Gb machine (Designer is allowed 16GB in the settings). Dragging things around is very choppy. If I restart Designer everything comes back up to speed and memory usage drops to around 800MB. Not sure if that's relevant as the undo buffer won't be using any RAM on a fresh boot. The second attached image is the perf capture after a fresh boot with the same scene loaded.
An interesting new symptom that has appeared in V2 is that the Designer process no longer exits properly when it's got into this slow state. I have to kill it with the Task Manager before I can launch it again. The application window is not visible, only the process still exists.
The culprit in both cases seems to be Serif.Interop.Persona.DisposableResources.Find() which, in my naive interpretation sounds like a memory leak or cycle in the Garbage Collector. If I break the debugger while the process is trying to exit it never leaves that Find() method.
Anyway, hope that helps. Happy do do any more testing as this happens pretty much every time I do any work in Designer.

@fabtho To change the Text Styles permanently for all future documents, do this:
In the Text Styles panel hamburger menu, enable Show Heirarchical (so there is a check mark by it). This should ensure the Base text style appears at the top of the list. Edit the Base text style that appears at the top of the list, change the font and any other settings to whatever you want. When you're done editing the style, click the OK button in the Edit Text Style dialogue to save changes. Again, in the Text Styles panel hamburger menu, Save Styles as Default.

If you start up a blank document, set the font to what you need and then go to Edit -> Defaults -> Save, then new documents should always default to that font. I got fed up with Arial being the default on my system!

Hi,
I've got a set of gradients in an Application Palette and it's really hard to differentiate between them as they all run into each other (see attached image). Even with the view set to the largest thumbnail it requires quite a bit to concentration to pick the right one!
I'm aware I could use "Show as list" to separate them out, but for my non-gradient palettes it's nice to see all the colours together and it's not possible to set a view type per-palette.
It would be super if there was an option to display gradients vertically in the Swatches panel. Or just display them vertically all the time! I can't really see an advantage to seeing them horizontally.
Cheers,
Mike

The gradient is displayed exactly as defined. If it is displayed vertically, it will be quite confusing for many users. However, it is true that the boundaries between the gradients converge, so the individual definitions are difficult to distinguish. It would help if the individual areas were separated by a small gap. Alternatively, you can use them to display a list (in hamburger menu, appearance).