loukash

Supposedly, a child was looking through his dad's desk drawers for a pencil or something & discovered an old 3.5" floppy disk in it. He asked his father why he had printed a 3D copy of the Save icon. 😀
Of course, there are now young people that would not understand what an icon of a rotary dial telephone or even a pushbutton one represented ... & very many who are not sure about analog clock-face symbols either.
Feeling old?

Speaking of UI design:
Seeing commands like "Speichern unter" (Save as) coupled with the symbol of a floppy disc in the year of 2023 makes me want to bang my head against a wall for no reason.
Yep, even seen that on Mac.

Mmmm… Freeeehand!  

Don't know about Windows, but Affinity on Mac is by far not the worst UI offender. Heck, even some of Apple's own apps are abysmally designed these days; the Mail.app being one such example that's been getting worse with each "upgrade" (although admittedly the Ventura version is slightly better than then one on Catalina).
One issue with Affinity is that apparently for cross-platform consistency, the UI uses lots of non-standard elements, rather than providing elements available via OS frameworks. What's even worse then: those custom UI elements are invisible to system-wide accessibility features, e.g. not accessible to Apple's System Events UI scripting.

At first I was rejected with "This is an invalid website. The website URL and e-mail address should be from an existing labels/packaging company."
22 months later I tried again, and all of a sudden my puny self was considered "worthy". Halleluja praise the Gawdz of Packz!

At first I was rejected with "This is an invalid website. The website URL and e-mail address should be from an existing labels/packaging company."
22 months later I tried again, and all of a sudden my puny self was considered "worthy". Halleluja praise the Gawdz of Packz!

dont make me cry @loukash ❤️

Mmmm… Freeeehand!  

Don't know about Windows, but Affinity on Mac is by far not the worst UI offender. Heck, even some of Apple's own apps are abysmally designed these days; the Mail.app being one such example that's been getting worse with each "upgrade" (although admittedly the Ventura version is slightly better than then one on Catalina).
One issue with Affinity is that apparently for cross-platform consistency, the UI uses lots of non-standard elements, rather than providing elements available via OS frameworks. What's even worse then: those custom UI elements are invisible to system-wide accessibility features, e.g. not accessible to Apple's System Events UI scripting.

Yep, that's still a major issue.
But as I said, since there is already some progress, they seem to be aware.

For demonstration purposes, I've now used menu comands, a few extra clicks, and proceeded generally very slllooowwwwllllyyy to show what steps I'm performing, but it all can be done within a few seconds with a few keyboard shortcuts and clicks:

aph_copy_paste_selection.mov The main thing to remember here:
A marching ant selection always affects the layer(s) selected in the Layers panel. If no layers are selected, there's nothing for the marching ants to, well, select. This is by design. Photoshop behaves the same unless when working on a locked background layer.
Hm.
When everything else fails, have you tried to:
read the manual? watch some tutorials? ask questions in the forum?

Fixed, thanks.

Same bug as this report: 
 

I agree. Affinity shouldn't "mess" with system-wide parameters.  
On Mac, you can always delete a system palette within Affinity via Window → Apple Color Picker.
You can even open the Apple Color Picker in any app you want by using this AppleScript one-liner: 
tell current application to choose color (No idea how it works on Windows.)

Clearly this request from V1 (2015) has been ignored, any chance of adding this function in V2 please? 
 

A "proper" QL preview depends on the file format accessibility it previews.
For example, a GarageBand or a Logic Pro project can also only quick-look the embedded PNG screenshot of your saved document.
Just like Affinity does.
To generate "proper" previews, such an Affinity QL plugin would always have to render the document as if you'd be opening it with an Affinity app. I don't think that's a feasible solution, hence the JPEG thumbnail rendering upon save.
What would be helpful though:
A preference setting à la InDesign where you can define the size and scope (which or how many pages or artboards) of the embedded preview thumbnail.
Because in most instances, I'd like to keep my file sizes small, so usually I'm fine with the current QL preview dimensions of Affinity documents.

Affinity is not a religion and Serif is not a church. At least not the last time I checked, hehe…  
When Serif are ready to announce a new product, they will.
Until then, all we can do is post feedback and bump existing feature requests to let them know what we'd like.
And yes, I'd love to have a modern equivalent of the good ole iView/Expression Media DAM, better yesterday rather than in ten years! Whether it comes from Serif or from someone else. (Some developers are already getting quite close to it, yet still not what I'd need. Dang.)

If there's no Serif Bot info in the post saying the issue was fixed then it wasn't looked at yet.

Um, yeah, sure… FWIW if Serif ceased support for iPads I (as a designer and illustrator) wouldn't be using Affinity products at all. I get that some folks really want a DAM, and some folks really want {insert your product/feature request here}, but please let's not minimize others priorities because they don't align with yours. 
At the end of the day it all comes down to Serif's priorities for their products, and their business.
 

Yeah, that's what I meant by "the embedded preview image"  

Hi all,
The team has been making good progress. I don't have any updates on a release date but please be assured we are not sitting on our haunches - we want to get this feature out as much as you want it out!
Naturally we've been exposing more of the apps' functionality to scripts, but we've been working on plugin-specific technology too. For example, there's a new asynchronous file i/o and networking API, initially driven by the Javascript layer but then we thought it would be good for the lower level C/C++ plugins to have access too. Obviously with local and remote i/o, we've had to be careful that a script isn't covertly sending user data somewhere, so we've introduced a permissions system for Javascript plugins - unless you allow a particular script network access, it won't be able to use the networking API. It may not be a big shiny WOW! feature, but it's important to get these things right.
Anecdotally, I can tell you we've actually used some scripts internally to do some genuinely useful stuff that would have taken literally days to do manually. One script I wrote optimised a document and removed about 60000 layers. There have also been relatively simple layout and alignment tasks that scripts can munch through in the blink of an eye. Last week I wrote a script that split a pixel layer into new pixel layers containing the blocks of grouped pixels. Even the pixel processing was done in the script - I didn't have to rely on the app to do the heavy lifting for me because our performance is good enough to implement DBSCAN in Javascript.
Please be patient. We know you all want scripting available yesterday, but we're getting there!

File → Reveal in Finder delete file in Finder Or correspondingly whatever the command is named in Windows.

That's what DAM solutions are for.
Affinity apps are no DAM.

There is also the question of which AI features it should implement.
Maybe they would consider those ideas but it is very unlikely they would even notice them here in the Questions forum. Those suggestions would be much more likely to be considered if they were posted to the appropriate Feedback & Suggestions forum.