nwhit

I checked one of the Designer brushes that is also (apparently, since it has the same name) in Photo and it does not have that option selected (no associated tool is selected). Yet in Designer, that brush has a "Brush" icon next to it. Of course, there is no option to select an "associated tool" in Designer, so still not clear why some brushes in Designer's Raster brush panel have that little icon and others don't. And I have not at this point imported any Designer brushes into Photo. As an aside, where is Serif storing brushes, etc.? I'm not seeing anything in the typical Application Support directory.

Just digging into Designer's brushes and noticed that some have a brush icon to the right of the stroke example, but for the life of me, I cannot find in the Help or online what that icon means and why it is only shown with some of the raster brushes. Could someone explain what it means? Thanks.

I know I was surprised because during the 1.7.2 beta testing, Eye Candy did launch in most (but not all) versions. Thus I was surprised when it did not launch in the final release. I did just try removing the directory listing in APh Plugins prefs, then adding it back in (relaunching each time). I also restarted my computer just to be sure. I trashed and re-downloaded and installed 1.7.2 from the Mac App Store again. But no joy. Still will not launch. I've also checked the Security/Privacy/Accessibility and tried adding APh for access, but that didn't solve it. Meanwhile, my Topaz Labs filter works fine and my Google Nik Collection filters all work. Eye Candy has and still does launch and work just fine from PS CS5. The only variable I can think of is the diff between the betas being from you versus the final release being from Mac App Store. And while we still haven't solved the bigger issue of rendering the Eye Candy interface correctly to be fully usable, I had been creating a few common presets in PS, then using those presets in APh betas, even though I could not correctly preview them. But now I'm stumped! Hope we can sort this out! I imagine if I had to, I could always purchase APh again through your store, but really hope we can get it work in the Mac App Store version (if that's the problem).

Interestingly, after going from the latest beta to the Affinity Store final 1.7.2 update, I also lost the text rulers on new and old documents. I quit the app and restarted which gave me back the text rulers, but odd they disappeared with the final version update. I'll have to watch if they disappear again.

Opened fine in the betas but does not launch in the final Mac App Store version.

As per the thread below, many are concerned that even in the latest Affinity betas any changes made in APub via SL to a linked file, the changes made within SL are not saved to the original APh or AD file, nor is the newly modified graphic changed to an embedded file. Just curious when/if this will be addressed so that we can really start to use this potentially great feature. I was hoping to see this in 1.7.2 but in testing today, still not working.

In v151 crashes both Nik and APh beta after selecting about the 4th "Recipe". Crashes when clicking on the notification dialog for losing previous settings. No crash report generated. Can select normal presets but the "Recipes" are what cause it to crash. Update: If I click the Do Not Show Again in the dialog, no crashes. Tried about 8 Recipes and saved the final one successfully. Thus probably related to handling that pop-up dialog.

Was replying to OP that there was no problem with text wrap for me in the new beta.

Same here. Just tried it on an existing and a new doc.

Still the same in v458

Sorry, forgot to add that. High Sierra. Metal on. iMac 27 2017 i5 Radeon Pro 580 8192 MB.

Just noticed an issue in the Hyperlinks panel where in the dark mode when double-clicking on the name to edit it, cannot read what is in the field much less what you're typing. The display is white text and white background. Minor thing but does make it tough to edit link names.

The latest beta is 1.7.2.442. Be sure that is the app version you are reporting on.

I kind of assumed that. Really wished it worked like so many other Mac apps. The reason for this "desire" is that it is not uncommon to mistype (or even misthink!!) a file name when originally saving, thus requiring a file name change. Hate to have to close the file, go to the Finder to change the name, then manually reopen the file with the new name (since the Recent Files dialog won't work after a file name change. Also saves having to do a Save As, then remembering to trash the old file later. Over the years, have had to do these Finder file name changes many, many times, and for a few other reasons as well. Always been simple on a Mac with apps automatically updating with the changed file name. The other worry I have is that if a person is not aware of this "limitation", and they do change the Finder file name, they may not be aware that changes made to the open file from then on will be a a newly created file using the original name, which may be quite different than the original name. And while I cannot say for sure, that might possibly lose Undos and History in the process. And it could create confusion when later looking for the correct and latest version of the file if the file name change is significant, thus putting it out of sequence in the Finder and Open dialogs. Don't know how tough it is to get this to work, but seems other apps do it reliably, so perhaps worth thinking about. Or at least providing some type of warning dialog if someone does this, and before the app "secretly" creates a new file with the old name (you won't know this until much later when you try to open the new file name and discover it's not the latest version). Thanks.

Works correctly! Thanks!

I read that in the beta notes, so will give it a try today. Thanks!

Crashing again with Recipes again in v150. It crashed after about the third Recipe selection was made. It didn't generate a Photo Beta crash report but the one attached has a time stamp at the same time, so may be the results. quicklookd_2019-08-05-144429_TRAC-Main17.crash

I did that for sending the file to you so that you'd have the images that are normally linked (as per a common instruction prior to uploading a problem file). Have been doing some more work this weekend with the new beta and have not had a reoccurrence of the crash when opening other files, so maybe a one-off for whatever reason.

Aha! Now I see what's happening! When the "place" cursor is hovering over an existing picture frame, it seems to automatically preview the placed item in that frame! That may be "by design", but it does make it hard to place new items on top of existing frames. Perhaps I am doing something the wrong way??? Update: I tried adding two new picture frames on top of the main picture frame to contain the two new psd files and seems to work better. Slower way to add minor graphics, but at least doesn't cause the issue reported in first post.

Have not had this happen before. Had a mutli-layer small advert and was going to place a couple art elements on top. However, when I selected the items individually to place (psd files), before clicking and dragging to place it, the main pic layer below it disappeared completely and a large, stretched version of the file to be placed appeared instead (see pics). Once I placed the 2 psd items, the display went back to normal, but this would, of course, preclude precise positioning when placing if a person were relying on the main picture layer. Very strange and can't say I've had this happen before in any of the versions. Can upload various files but would need a link.

With both Metal display and compute on. Previously did not work properly but the latest betas work much better with metal now. Still might be a few glitches with metal but not with my common workflows.

As per my other post on the newest beta speed improvements, with the new 1.7.2 betas, my speed is massively faster than 1.6.x or 1.7.1. And that's processing 24MP RAW 3-bracket HDR merging, tone mapping, plus other touch-up tools, then custom export. High Sierra, iMac 2017 i5, Radeon Pro 580 8192 MB, Metal display and compute. Cleared up the slowness with the 1.7.2 betas and made it significantly faster than 1.6.7. In fact, too fast for me to even get some coffee drinking done while I work! (I typically do several hundred of these RAW develop/merge/tone map/touch up/exports a day, so am very familiar with typical speeds.)

I've uploaded the file. However, it only crashed the one time after updating the beta. Since then it opens fine and I haven't had issues opening others so far, although I haven't had time to test a lot of previously created files. I also had to go into the file and embed the images and re-save in the new beta, so not 100% the same file. Don't know if the crash report showed anything strange but thought I should report it.

I agree that this needs to get sorted out better. Really a remarkable capability, but has some very rough edges that make using it a bit dangerous as bergdesign said. I'm just now testing the newest beta 442 and was wondering iof this has been resolved, but it hasn't. Using Studio Link to edit a linked APh file does not change the original APh file, nor does it create a new, embedded version for "safety". I would think this should have a preference where you could select (maybe per document) if edits in SL update the original file. But if it doesn't update the original file, it does need to embed a new version so that edits don't get lost.

Crash report attached. High Sierra. Affinity Publisher Beta_2019-08-01-124602_TRAC-Main17.crash