On macOS, when you drag a file into an Open or Save panel, the panel’s current directory switches to the dragged file’s containing directory and highlights that dragged file.
On Windows, when you drag a file into an Open or Save panel, the dragged file is moved from its original location to the panel’s current directory. It is a destructive action!
That may be one little thing but it’s part of a whole number of reasons why I dislike using Windows. Alas, all the counter arguments to any and all reason I might give for preferring macOS do sound like toilet-plunging family members.
Note that on windows there are at least 3 generations of save dialogs. Which one you see depends on which generation of the api is used.
The most common one is the more modern which is basically just an explorer window. Dragging a file into an explorer window works that same regardless of whether it’s an open/save dialog or not. It’s a move/copy operation (depending on e.g modifier keys).
I didn’t quite get the point of dragging a file to a save dialog at all though? (Assuming that’s what you meant by panel) is it that you wanted to use it for navigate+set-name? That to me as a windows user seems alien. I expect it to work as an explorer window! Expectations are everything. The principle of least surprise doesn’t really work cross platform I guess.
Yes, a save panel is a save dialogue. It’s just Apple terminology.
> I don’t quite get the point of dragging a file to a save dialog at all though?
On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen.
This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling behaviour out of the box) and can be further enhanced by an app’s developer.
That begins with behaviour you might ordinarily expect from most apps: drag a image file from Finder into a Word, it should embed the picture; drag an audio file from iTunes into an open Audacity project, it should add the audio as a new track; or, drag highlighted text from a text field to the desktop and it will create a text snippet file containing that text.
On Windows, apps need to implement this behaviour manually. Figuring out how to deal with certain file types is not built into every app out of the box.
On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. It’s a fundamental feature of Cocoa, open which all native apps are built, so every app gets the correct behaviour for free. Dragging and dropping is super powered on Apple platforms.
For example, proxy icons: on any given document window (a window for an open document, like a Word document, Photoshop document, Final Cut project, etc), the name of the document is preceded by an icon that represents the document. You can actually drag that icon off the window’s title bar to any other on-screen element that supports receiving dragged objects — an open document, a Finder window, an email, a text field, etc.
I say all of this to cement one point: dragging and dropping is a key interface metaphor on macOS and iOS/iPadOS.
So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.
Or perhaps I’ve just downloaded an image from the web that I want to share with my friend. Again, I can open up my favourite messaging program, click on the Add Attachment button, and drag the image in from my Dock’s Downloads stack.
(Although, that’s a slightly odd example; I wouldn’t bother with the Add Attachment button, I’d actually just drag the file directly from the Downloads stack on to the app and expect it to figure out what I want to do)
For save panels, I might already have a folder open in Finder where I want my document to be saved. When I save the document for the first time and the save panel appears, I can either drag that folder or its proxy icon from Finder straight into the save panel — bam, the save panel is pointing to the correct place.
Or perhaps I want to save a file into the same place as an open document. Again, I would just drag the proxy icon of an already-open document into the save panel, bam, we’re looking at the right folder.
Notice: these actions are non-destructive. Non-destructive actions follow the principle of least surprise. All I’m doing is telling an open/save panel where I want to be.
> That to me as a Windows user seems alien. I expect it to work as an Explorer window!
Ask yourself what the basic function of an open/save panel is: to select a location for a file (and in the case of a save panel, give it a name). Of the four CRUD operations, only C and R are directly relevant.
Something shouldn’t act as something else, especially if it’s destructive. That, in my opinion, violates the principle of least surprise — an interface to C or R should not U or D.
The only thing I expect to act as an Explorer window is … an Explorer window.
> On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. It’s a fundamental feature of Cocoa, open which all native apps are built, so every app gets the correct behaviour for free. Dragging and dropping is super powered on Apple platforms.
This isn't true. It is true that it's built into the development tools and toolkits that Apple provide and expect you to use when writing software for their platform.
But it's not particularly hard to avoid. Google "nibless development mac" and you'll find some links that reveal how to develop full GUI apps on macOS that do not rely on this infrastructure. Regardless of whether or not you think this is a good idea, please rest assured that an application developed in this way does not share the "OS-level" drag behavior that you describe above. For it to behave in this way requires explicit code to handle notifications delivered by the OS.
Why does this matter? Because those Apple SDKs that make all this happen "seamlessly" are hard to use if you want to do cross-platform development. Qt (and GTK) work at trying to take care of this for you, but its not 100%, precisely because (as you note) this concept doesn't exist on other platforms.
So yes, from a user perspective this is a "universal" feature of apps on macOS. But it does not come with the OS - it comes from only developing apps using Apple SDKs and tools, which makes it harder for people doing cross-platform development to correctly play the game in the expected way.
My only response to that is apps that aren’t made to be good macOS citizens wouldn’t even vaguely register on my radar as ‘native’, even if they link against Cocoa.
‘Native’ on Apple platforms isn’t just a technical description, it’s also about UI and, more importantly, UX. Of course, Apple are starting to muddy the waters with UIKit for Mac — but even then, the fact that iOS apps can now run ‘natively’ on macOS goes a long way to showing that just because an app links against the relevant frameworks compiled for the right processor architecture, that doesn’t make it native in the Apple-y sense.
Apps made using cross-platform frameworks like Qt and GTK certainly don’t register to me as native. They don’t just work differently, they even look odd. I don’t think this fazes Windows and Linux users/developers as much because there has never been any level of consistency remotely close to what Cocoa and macOS offers — if an app puts a few buttons in a slightly odd place, that’s not seen an a problem.
So I agree with your point on a technical basis that my assessment wasn’t 100% technically true — but I think from the point of view of what ‘native apps’ means when discussing Apple platforms, I don’t think I’m too far off the mark.
> My only response to that is apps that aren’t made to be good macOS citizens wouldn’t even vaguely register on my radar as ‘native’, even if they link against Cocoa.
Sure. But two things:
1) I wasn't saying that an app that use nib-less techniques couldn't do the right thing - it could. It could appear totally native if someone just does the work.
2) There are several pro creativity apps (Logic, Mainstage being the biggest) that are actually Apple products but they do not adhere to Apple guidelines. They use non-standard widgets, do not fully follow desktop interactivity guidelines, use the keyboard in non-standard ways. So even within the set of Apple's own applications, there are things that are about as different as a Qt or GTK application might be.
I agree on those points. Especially on the first: when people put in the hard work, those pay dividends — but often mean those apps lag behind when Apple does breaking changes (which must happen at least every 3 or 4 years).
Apple’s Pro-apps are very alien. I expect that’s because they appeal to an audience that spends almost all their time in them, not moving much between a whole bunch of apps.
Lastly: Nothing’s ever as non-native as a GTK app. :D Qt and Wx apps do an infinitely better job than any GTK app I’ve seen for macOS, even if I don’t think they come very close aside from tapping into Cocoa’s control drawing.
> So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.
On Windows you can drag the file right onto the 'Browse...' button on the web page. (this does require some precision, as otherwise you'll open the file in the browser)
> Something shouldn’t act as something else, especially if it’s destructive. That, in my opinion, violates the principle of least surprise — an interface to C or R should not U or D.
Perhaps I'm too used to Windows's idiosyncrasies, but an open/save dialog is an Explorer window (at least in a functional sense). When you drag a file onto it, it does the same thing as an Explorer window. This does not seem that surprising to me.
> On Windows you can drag the file right onto the ‘Browse…’ button
I know, but I was illustrating a point about how the open/save panels work. That’s why in the following example, I mentioned that I’d just drag straight into the app.
> Perhaps I’m too used to Windows’s idiosyncrasies
Yes, you are. If you want an Explorer window, you should open Explorer. When you see a file picker dialog, you don’t see an extra Explorer process spawn nor does that dialog get added to Explorer’s list of windows.
> This does not seem surprising to me
Because you’re looking at it from a technical level, not a user interaction level.
At the interaction level, what is the goal of an open/save panel? To pick a location. It doesn’t fundamentally need to do or be anything more than that. That its default behaviour is destructive is classifiable as ‘surprising’.
Entirely agree with et dry thing you said. I just wanted to say, re
> For example, proxy icons
The way they are buried in Big Sur, and often invisible unless you mouse over where they are by accident is my biggest gripe with the update. This is fundamental in how we interact with documents on that platform, and one of its great features. What were they thinking?
I suppose it comes down to the fact that sidebars can now inhabit the space usually reserved for title bars. It’s not a design decision against which I have any opposition so long as draggable space remains (and there usually is; I complained to Apple during the Big Sur beta period and they made some spacing adjustments).
But I agree, those icons coming and going can make using them something of a pain. It also makes less clear what apps actually have them. An option in System Preferences to make proxy icons show all the time would be lovely.
Thanks for this great comment! As a non Mac person who has occasionally used a Mac, it makes perfect sense.
> The only thing I expect to act as an Explorer window is … an Explorer window.
One thing I wanted to add from my perspective (software engineer, use Linux and Windows): if I observed that the “save” button had created a literal Explorer window, then I think I would expect it to function as a Explorer window. I’m not surprised by that because I can recognize that Microsoft has taken the approach of implementing everything they can using Explorer. This gets back to what was discussed in the article actually!
Overall I think I prefer the approach Apple takes on this problem.
If the “save” button did indeed create a literal Explorer window, I expect it to come with all the trimmings — but it doesn’t. Plenty of what makes Explorer what it is aren’t part of the actual control that both Explorer and file picker dialogs use.
To me, thinking of file picker dialogs as literal Explorer windows is as contrived as file picker dialogs not offering full CRUD abilities — except one approach is vastly friendlier and safer.
I understand the technical decision, too, but there’s nothing that could prevent Windows from making file picker dialog behaviour non-destructive.
Indeed. Little things like Apple’s implementation of drag-and-drop being lost in this sea of ugly, slow Electron apps is something that you just can’t explain to Electron developers — they make for Windows first, they have no idea what Mac users complain about, and even when we tell them they think we’re being silly.
As per the comment to which I replied asked (although I believe GP asked in good faith): “why would you want to do that anyway?”
Because that’s how we do it on macOS. That could be why we use macOS. If you care so much about letting macOS users access your app that you went with Electron rather than writing something Windows-only, it shouldn’t be hard to learn to respect the Mac platform and, more importantly, its users.
> On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself.
I can't see how it's any more part of "the OS" in MacOS than in Windows?
> On Windows, apps need to implement this behaviour manually. Figuring out how to deal with certain file types is not built into every app out of the box.
Every app on both Windows and MacOS have to implement most drag & drop handling themselves. You get notified that the user has dropped some data, and you implement it.
Some controls are basically miniature apps and can handle some of it (e.g. a text control could as default accept dropping text into it) but that's a rare edge case and in most situtaions you are obviously going to have to implement it yourself. 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.
> drag a image file from Finder into a Word, it should embed the picture; drag an audio file from iTunes into an open Audacity project, it should add the audio as a new track; or, drag highlighted text from a text field to the desktop and it will create a text snippet file containing that text.
File drag events work like that on windows. Text selections aren't objects in that sense (dragging just changes the selection) so that's typically not a draggable entity.
A picture is, and behaves like you expect (e.g. insert into a word document).
> I’d actually just drag the file directly from the Downloads stack on to the app and expect it to figure out what I want to do
Of course, a chat app has drag and drop for pictures into chat messages on both windows and mac. Otherwise it would be a pretty terrible chat app. Any cat app could of course be terrible, and there is every chance that more chat apps are terrible on windows - but that doesn't change the point. If you launch Teams or Slack or whatever and drag a picture from a word document into it, it will add it to your chat message. On both windows and mac.
> So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.
As a windows desktop developer myself (who struggle a LOT with drag & drop) I can see myself implementing something like this. But it's always a question of user expectation. First of all, there is no proxy icon! I'd love to see those in windows, but it's not currently part of the UX. As such, you don't have a "drag source" for open documents. To get anywhere to drag from for an open document you'd need to open explorer and browse to the location. But that's the exact same effort as doing it in the file dialog, so what's the point? As you can see, the mistake wasn't "poor handling of drag & drop" here, the missing capability I think is the proxy icon.
> All I’m doing is telling an open/save panel where I want to be.
I want to repeat - and this is important. The windows save panel isn't special. It's a full explorer file list, plus a file name textbox. One can argue that this is a poor choice - but that's what it is. It has different areas (a filename textbox, a file listing view etc). The file listing view is just like any file listing view in any explorer window. As such it has all the capabilities you expect. If you select a file and hit delete, it's deleted. If you want to create a new folder - perhaps the most common operation for a SaveAs dialog, it does that. So here microsoft had a choice: if you drag a file onto this area of the dialog, should it work like all the other explorer file listing areas in the OS, or should the Open/Save dialogs have special treatment? I think you could argue both ways there, but there are definite drawbacks to both. It's absolutely not a clear cut case of "Well that dialog should be non-destructive so dropping should do navigation! case closed!". This doesn't mean you can't have that functionality anyway. You could just make a drop of any file elsewhere on the dialog (such as on the path-section of the dialog) initiate a navigation, for example.
> The only thing I expect to act as an Explorer window is … an Explorer window.
I think this is merely a UX choice not a clear case of "well this way is better". As I said there are several types of file dialogs in windows, and some are more like what you describe and not "Just an explorer window".
Perhaps if windows had proxy icons, there would never had been a thought to make the latest gen file dialogs be full explorer views, because then the proxy icons would have made drag to navigate work?
I use both windows and mac today, but growing up on windows, I use MacOS less and I use it like I would use windows. Which means it's extremely frustrating. For example, I had no idea whatsoever that the little icons in menubars (I just learned they were called proxy icons) were draggable. I always launch finder like I would launch explorer and drag things around, even documents I already had open... It sounds to me you have a few such discoveries to make on windows which would make the experience less frustrating.
> 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.
> 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.
The ability to set the destination folder to a folder you have open in a file manager window without copy-pasting the path is convenient. But at the same time, the file-management capabilities of the macOS file picker are basically non-existent (although there seem to be more right-click options in Big Sur?)
Yeah, there are file management options available via a context menu. I believe certainly keyboard shortcuts also work (Cmd-Del to send a file to the Trash/Bin, Return to rename a file, etc.).
Having switched from Mac OS to Windows a year ago, this specific thing had annoyed me to no end, and there are no good ways to replicate that behaviour (believe me, I’ve looked!)
What I currently use is Listary, which automatically switches open/save modals to the last used Explorer window location. However, I’d rather switch to something that offers this functionality exclusively.
You can also see this AHK script which I found in a comments section here a few days ago - https://pastebin.com/cmLVFdbB
See you've been conditioned to think that some file views are different from others. On Windows, a file viewer is a file viewer is a file viewer. So yes, dragging a file from one file viewer (windows explorer) to another one (which happens to be inside a file save/open dialog) is a move action. I love this and wouldn't have it any other way. Although I agree it should be a setting. Although perhaps Apple has patented it. Gotta always remember that GUI patents are a thing.
> See you’ve been conditioned to think that some file views are different from others
They are different. Their purpose is different. It is the purpose of an open panel to let me pick a file/folder location. It is the purpose of a save panel to let me pick a folder to save a file.
User interfaces and user experiences go hand in hand. A user interface should be purposeful. It creates a better experience.
Sure, you can get used to an open/save panel having destructive behaviour and it can be handy — but that doesn’t make it a better user experience. It puts destructive actions front-and-centre, violating the element of least surprise and potentially endangering user data.
> Although perhaps Apple has patented it
Doubtful. It’s just a consequence of Microsoft using the same Explorer control throughout the operating system without making any adjustments for behaviour.
On Windows, when you drag a file into an Open or Save panel, the dragged file is moved from its original location to the panel’s current directory. It is a destructive action!
That may be one little thing but it’s part of a whole number of reasons why I dislike using Windows. Alas, all the counter arguments to any and all reason I might give for preferring macOS do sound like toilet-plunging family members.