5 ms·

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

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.

alkonaut 6y ago
What’s a save panel? You mean a save dialog? 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.
- zapzupnz 6y ago
  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.
  - baxuz 6y ago
    I love this comment. One of the reasons I prefer using MacOS as my daily driver even though I have a lot of complaints. Sadly, due to the ever-increasing number of non-Cocoa apps (primarily Electron ones), these features are getting the boot.
    - zapzupnz 6y ago
      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.
  - kergonath 6y ago
    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?
    - zapzupnz 6y ago
      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.
- Kwpolska 6y ago
  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?)
  - zapzupnz 6y ago
    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.). You can also choose to Show in Finder.
CiceroCiceronis 6y ago
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 https://pastebin.com/cmLVFdbB
- zapzupnz 6y ago
  Good to know that there are some things out there, though. A few glasses of ice water in Hell, so to speak.
phendrenad2 6y ago
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.
- zapzupnz 6y ago
  > 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.

alkonaut 6y ago

What’s a save panel? You mean a save dialog? 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.

zapzupnz 6y ago
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.
- baxuz 6y ago
  I love this comment. One of the reasons I prefer using MacOS as my daily driver even though I have a lot of complaints. Sadly, due to the ever-increasing number of non-Cocoa apps (primarily Electron ones), these features are getting the boot.
  - zapzupnz 6y ago
    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.
- kergonath 6y ago
  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?
  - zapzupnz 6y ago
    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.
Kwpolska 6y ago
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?)
- zapzupnz 6y ago
  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.). You can also choose to Show in Finder.

CiceroCiceronis 6y ago

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 https://pastebin.com/cmLVFdbB

zapzupnz 6y ago
Good to know that there are some things out there, though. A few glasses of ice water in Hell, so to speak.

phendrenad2 6y ago

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.

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