3 ms·

Text > I can’t see how it’s any more part of “the OS” in MacOS than in Windows? Think of “the OS” as the whole package, not just “system components and softwa

Text > I can’t see how it’s any more part of “the OS” in MacOS than in Windows? Think of “the OS” as the whole package, not just “system components and software other than user-installed applications”. Because it’s implemented at the system framework level, and there’s basically only three system frameworks for developing macOS apps — Cocoa, UIKit for Mac, and SwiftUI — and two of them call into the other. That means practically every application (well, maybe not every; the number of UIKit for Mac apps is on the rise) shipped with macOS is a good macOS citizen, compared to Windows which is a mish-mash of apps built with all the many various application frameworks that have shipped with Windows. 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. > Every app on both Windows and MacOS have to implement most drag & drop handling themselves. On macOS, only custom handling is required. When an app is built from standard components, Cocoa does it for them. 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. > If you are the audacity developer you’ll be notified that someone dropped an mp3 on the surface of your window. You’ll have to take it from there. That’s 100% the same thing in windows. I’m aware of that. Actually, I mentioned Audacity in a section where I illustrated three examples of where one would expect an application to accept something that has been dragged in. That wasn’t an example of anything exceptional to macOS. > File drag events work like that on windows. Again, you’re on a section where I’m illustrating standard, expected behaviour for drag-and-drop. I don’t start really talking about anything macOS-specific until the section where I mention proxy icons, so I’ll respond to the next section. > First of all, there is no proxy icon! I explained proxy icons as an illustration of why a Mac user might want to drag-and-drop into open/save panels as a means to directly answer your question on that very point. > the missing capability is the proxy icon You got a bit hung up on the proxy icon. It was just one way that a Mac user might want to drag and drop. I mention a couple of other ways that a person might want to drag and drop something into an open/save panel. The lack of proxy icons in Windows is orthogonal to the point of open/save panels being needlessly destructive. > I want to repeat - and this is important. The windows save panel isn’t special. That’s a technical detail. That has nothing to do with the merit of whether or not it should be that way. > One can argue that this is a poor choice Yes. > but that’s what it is Yes. That doesn’t make it good. Microsoft has demonstrated an affinity for reinventing their own user interface elements with breaking changes in each iteration. There was nothing stopping them fixing this behaviour then, there’s nothing stopping them doing it now — there is absolutely no reason an application should depend on destructive behaviour. > It’s absolutely not a clear cut case of “Well that dialog should be non-destructive so dropping should do navigation! Case closed!” That slightly misrepresents my argument. I don’t believe it’s necessary that Windows open/save panels should behave as on macOS. I 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. That could even be fixed with a simple confirmation dialogue. > there are several types of file dialogs in windows, and some are more like what you describe Why are there non-destructive and destructive file dialogs? Why are destructive ones the most common? > Perhaps if windows had proxy icons Irrelevant. Protecting user data doesn’t necessitate proxy icons. Microsoft simply chose to reuse a control with zero affordances for use-case; they made the choice not to protect user data. > because proxy icons would have made drag to navigate work? You’re stuck on the proxy icons. They were just one thing you could drag. > It sounds to me you have a few such discoveries to make on windows which would make the experience less frustrating I’ve been using Windows for the past 25 years. I still use it today, every day. I don’t have any sudden discoveries to make, I know it back to front. With every release, it deviates worse from its own standards than any UIKit for Mac app ever could from regular Cocoa. Fundamentally, Windows is composed of several incompatible technologies that all work completely differently from each other because of historical internal competitiveness from a fractured company. That legacy lives on today — and worsens with each release as Microsoft continues to pour efforts into other application frameworks (WPF is deprecated; UWP is unloved; WinUI is supposed to unify them; but React Native is more likely to have an impact), creating massive schisms in the consistency of the user experience. When Windows’ absolute basic components, the user interface elements you encounter in every app, are clearly the product of some technical desire for standardisation on a single control rather than any real desire to protect user data, I’m inclined to think the user experience is not at the forefront of Microsoft’s design philosophy. But that’s not because of a lack of proxy icons.

alkonaut 6y ago
> 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.

alkonaut 6y ago

> 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.