LCamachoDesign

Yeah, this is pretty much my take. And we've seen mergers and acquisition on the design/software enough times to know this will likely end badly. I mean, just look at Gravit Designer -> Corel Vector after the acquisition, or even more recently Vectornator -> Linearity Curve after VC poured in. This is why we can't have nice things.

Wait, what? There are key objects in Affinity? When did this happen? I just tested it in 2.3 and it works! I had no idea. Is this even in the documentation? Well, I guess finding out there's key objects is the best feature announcement! 😂😂

Placing an image and trying to set its scale on the toolbar is basically impossible. Steps to reproduce: Create a new document, I've used a simple press ready A4, 300 DPI Drag and drop an image into the newly created document, I've used this from Unsplash Select the image and use the toolbar to set a percentage scale, such as 50% Notice the image is scaled, but to a completely different value Keep trying to scale the image, the values will increasingly become completely erratic (!!!) Notice that trying to set a specific DPI value, such as 300 or 600, works as expected See the attached video below for a visual guide: Erratic Percentage.mp4 Thanks!

Right clicking a swatch created on any document palette created after the first one will no longer have the Edit, Rename and Delete menu entries active. See the image below: Steps to reproduce: Create a new document Create a new document palette, name it 1 for easy reference Create a new global swatch, make it spot to enable the Rename Spot menu too Right click the newly created swatch See that you can edit, rename and delete this swatch Create a new document palette, name it 2 for easy reference Create a new spot global swatch Right click this new swatch, notice the disabled menu items Creating further palettes and swatches Notice the problem continues Video guide below: Swtaches menu.mp4 Thanks!

Small UI bug when the Swatches Panel view option is "Show as list" and a swatch is set to overprint. This is how the documentation shows how the swatches should look: This is how the show in "normal" (?) mode, and it's correct: And finally, this is how the look like in "Shows as list" mode, we can clearly see the grey circles are not being correctly cropped and overlap the swatches above: Thanks!

Just to let you know this is still happening, and only in Affinity apps. No other apps have this problem, so I'm not changing system settings just for this. Can you please look up what's wrong with your icons? More importantly, whatever happened to the mini icon over the file explorer thumbnails? Attached is an example of how Blender does it. Affinity used to do this as well, but somewhere along the way this was lost, and it never came back. So now, when we export a PNG file next to the source file, both thumbnails look exactly the same. The only way to tell them apart is by hovering the file and waiting for Explorer to say what file type it is. Thanks!

I see. But in that case, it's still a problem in Affinity, and not with my system. You should be using the value marked in green, "decimal separator", since that's literally what it is. Instead you seem to be using the "list separator" value marked in red, which is the incorrect value to use (and also; is the correct value for a list separator, so I'm not changing it, it would break stuff elsewhere). Thanks!

I've posted about this before, but Serif could simply use SAM-HQ and be done with it: GitHub - SysCV/sam-hq: Segment Anything in High Quality

That just speaks to exactly what I was saying. The field changes too fast for wasting any time doing custom solutions. When I posted, the only thing you could run locally was Stable Diffusion 1.5. While that works, the quality was pretty substandard, but you only needed a GPU with 4Gb VRAM. Yes, you could use custom checkpoints and LoRAs for waifus, but... that's not the scope here. Jump forward to today, and now you can run SDXL locally. And the quality is much higher than 1.5, vanilla SDXL is ballpark MidJourney 4 I'd say. With ControlNet and LoRA / LyCORIS I'd say you get MidJourney 5 level of generation. But you also no longer can run with 4Gb VRAM, you need at minimum 8Gb, with 12Gb being the recommended value. Basically, you need a 3070 or 4070 and up. Yes, you can use quantization and other fiddly trickery to run below that. I can run SDXL locally on my M1 iPad Pro, but you're looking at 5 minutes per image, it's just not realistically usable. But like you said, it doesn't actually change my initial point, it's still better to have a plugin to connect to these generators. Again, looking at back to when I first posted, Automatic1111 was the way to run SD locally. Fast forward to now, and ComfyUI is the way to do it. Even when A1111 tries to catch up, with the 1.6 release a few days ago, it still can't catch Comfy, it doesn't have support for Control LoRA, and that's a massive downside IMHO. If Serif were, back then, to try porting A1111 into the Affinity suite, that time would've been wasted, they'd need to scrap everything and start again with ComfyUI to be competitive. So yeah, have a plugin system, and let others do that job. This is not speculation either. Just look at Krita, people spent time doing A1111 plugins for it last year... fast forward to today, and both top plugins have gone belly up. The development is now on the ComfyUI plugin hosted at CivitAI.

Bumping this to let you know it's still happening in 2.1.1 and literally all other document icons from all other apps I have installed do not have this problem. Also, none of the options you listed on your workaround @Callum would work as they simply do not exist anymore. These were for Windows 10, and I'm on Windows 11 (and was on 11 too at the time of my OP) where they no longer exist. Thanks!

Steps to reproduce: Create a new document Draw any vector shape Attribute a fill colour to the shape (for easier bug visualisation) Attribute a stroke colour to the shape Set the stroke width to a large value (for easier bug visualisation) Set the stroke colour to none, but leave the stroke width unchanged Notice the object is only showing the fill colour as expected Use the command Layer > Expand Stroke Expected result is for nothing to happen, as the object has no visible stroke. Instead an empty shape in the form of the invisible stroke is created. See attached video for a visual guide to this bug. I can see the logic of why this is happening, the stroke is still "there", it just has the colour of none. But that's not what a user would be expecting when using this command. It particularly aggravating if you have hundreds of objects with tiny stroke widths (the 0.2pt default), and then you expand everything at one to "bake" the design for print production. And do printers hate invisible objects with a passion, it can really mess their low memory equipment. You can't even use the Select Same command to catch all these objects because of this other issue I reported: Suggested remediations: Make the Expand Stroke command ignore any strokes with the colour of "none" Force the object's stroke style to "No Line Style" when it has its colour is set to "none" Either remediation would fix the problem, but implementing both would probably be the ideal as that's what I'd expect the app behaviour to be anyway. EDIT: Additionally, setting an object stroke style to "No Line Style" should force the stroke colour to be none. Otherwise you end up with the situation you select a shape apparently without a stroke, then use the Select Same > Stroke Colour and... nothing happens. The object you selected happened to have a orange stroke set to 0pt width. You can still try to use the Select Same > Stroke Weight > Equal to try and get around this, but it sure is a lot of workarounds to workarounds. Also, why is it Select Same > Stroke Weight if the Stroke panel refers to this object property as Width? Temporary workaround: Select one object with the stroke colour of none Use the command Select > Select Same > Stroke Colour Open the Stroke panel and set the stroke style to "No Line Style" Expand Stroke should now be safe to use (maybe, triple check just in case, you don't want to rouse the anger of a print plant operator) Thanks! Gravação 2023-07-20 144004.mp4

That's a good workaround. It worked. It would still be better to have this fixed in a future build. Thanks!

I know there's a number of Expand Stroke bug reports, but I don't think I've seen any reporting on this particular behaviour? The best bug description is actually show it visually. I've also attached a sample Affinity file for the development team to investigate. Thanks! sample file.afdesign

I'm just going to add what I think it's an important technical point, rather than discussing thread locking vagaries. Serif themselves should not add any AI related features to Affinity. This field is in constant change at this point in time. Plus, due to the nature of how it works, i.e.: needing vast amounts of compute power that are unavailable locally to nearly all users, the most likely future will be that a considerable number of cloud AI image generator and editor APIs will exist in the market. As such, what Serif should be focusing is what I've already mentioned dozens of times. Plugins and scripting. Plugins and scripting should be their top and only priority. Then users and API providers will be free to add whatever generative AI they fancy. Or none if they dislike, do not have use for, or simply disapprove of its usage. Furthermore, when the field inevitably changes, all that needs to change is the plugin/script, and that will be the responsibility of the creator, be it a user or API provider. Serif should not, and must not, spend their time chasing this industry. It changes too fast, it contains too much, it's just too much for any single company to keep up. It also gives the user freedom to use any provider they personally like, rather than being forced to use whatever Serif would choose. Thanks!

Ok, I can see the argument here. I'm not sure why anyone would want to select layers and groups in this way, but maybe it's useful to someone? Maybe this could be an option on the Select Same menu, like the Select Hidden Objects. It could be called "Select Layers & Groups" and be disabled by default? Thanks all!