> Some parts of Windows are UWP. Some are Win32. Some are WPF. None of them can be expected to behave identically. Many of them don’t behave the same way as basic system apps. Explorer behaves nothing like Settings.
As far as I know there is only one one system for drag & drop so while it's certainly true that apps look like a mix of of every framework on earth, I don't think this makes drag & drop any less a core OS feature on Windows. Dragging from UWP to WPF to WinUI to Win32 works just as well as between two apps of the same kind (As far as I'm aware). Of course since there ARE no "standard drag & drop" thing - e.g. because text snippets aren't draggable so it's only app-specific objects that can be dragged.
> These are not rare edge cases — these are buttons, text fields, text areas, image wells, and all the other basic components that make up the majority of apps.
Maybe there are interaction modes I'm not aware of but apart from dropping text into text fields which basic components actually give meaningful default interactions? Dropping text or images into a document needs a per-app implementation just like the mp3 in Audacity. Can you give an example that isn't just a text field? For example what's the typical use case for dropping something on a button?
> just believe user interfaces whose purposes only cover two of four letters in CRUD (specifically [C]reate for saving a file and [R]ead for opening one) should avoid being destructive.
The topic of this post is "why are there no thumbnails in the gtk filepicker"? The anwer is that there is a thumbnail system in the explorer (nautilus) but the developers chose NOT to use the explorer component in the file picker. So the capabilities for browsing files diverged and would require duplicated effort to do what people expect from Nautilus, inside the filepicker. This had also happened in Windows - and this I assume is why explorer is now part of the FileDialogs in Windows. I don't mind it being a full file browser experience (I like it) and I also think it's pretty easy to rationalize the decision to make use of the system wide file browsing experience here. No windows user ever expected anything else. I'd always want my file open dialog to accept a dragged file to mean "move/copy file there". But I'd also gladly take a drop on the path part to mean "change location".
> Why are there non-destructive and destructive file dialogs? Why are destructive ones the most common?
There are older and newer APIs, even within the same frameworks since Win32 2020 is different from Win32 1990. A new app showing a file dialog would typically get the "new" one. An old app making a call to show a file dialog will always get the old one - even on a new version of windows. The reason they can't just redirect those calls to show the new one, is because these are objects that the app can also modify/customize the dialog with code that doesn't make sense for the next gen dialog. So all generations of the APIs and all the appearances of the dialogs must remain available otherwise those apps would risk breaking. E.g. a 90's AutoCad would hijack the window area and render a preview of the drawing to the right of the file list. In the modern dialog such previews are handled by explorer plugins instead of a hack to draw a picture in the dialog surface itself. But obviously that 90's AutoCad program isn't changing, and must continue to run forever. So it gets the old dialog. And obviously between different toolkits the dialogs could change just like between Cocoa and something else.
Of course, ALL file dialogs allow selecting any file and deleting/renaming it - so they are all 100% "destructive" and all have both "U" and "D" in CRUD if you want, apart from handling the job of selecting a file name.
I'm not sure whether the older ones handle drag-drop or not (good question). If they do, I'm pretty sure they do exactly what the new one does, i.e. actually move/copy a file into the filesystem at the shown location.