monodevelop

monodevelop copied to clipboard

I don't know why, but we don't exit if the user closes the main IDE window on Mac. Instead we just hide it (we event don't minimize with the typical animation).

This patch removes the DeleteEvent override on Mac and lets the main Window close as expected (handled by DefaultWorkbench.OnClosing). For this to work correctly we also need to loop the IdeApp into the closing process, because our NSApplication.SharedApplication.Delegate.Terminate handler relies on IdeApp.IsRunning to be correctly set, in order to terminate MAC process correctly.

Fixes VSTS #561910

Most macOS applications don't exit when closing the main window. This must be somewhere in the HIG. /cc @vancura

Ok, this is stupid. macOS Apps usually don't exit, when the window is closed. But our icon behaviour is weird.

However the DefaultWorkbench patch still makes sense. I'll split it.

Re HIG: only applications with document windows don't quit. Take a look at System Preferences, it quits as soon as you close the window, similar to a lot of other no-document apps. That staying in background is there so you can open another document. We have just one window, so it makes sense to quit as soon as you close that single window. /c @hbons

only applications with document windows don't quit

I don't think that's true. Examples: iTunes, Calendar, Mail, System Monitor

Another idea that comes to mind is fully closing the currently opened workspace and show a clean slate workbench when clicking the dock icon.

I don't think that's true. Examples: iTunes, Calendar, Mail, System Monitor

All the application you've listed are meant to run in background. iTunes plays music, Calendar and Mail need to be always accessible, System Monitor is a special one, but it has some always-running features.

Apple HIG doesn't say anything about that, I've just spent good 15 minutes looking for that information :)

VS also needs to run stuff in the background sometimes, when you debug, build, deploy, run tests, etc. The IDE also needs to be always accessible for me, since I spend 90 of my work time on it.

Hhm, interesting. Xcode and VSCode exit, too. And Android Studio closes the current project and shows a welcome screen. So it's actually unexpected for someone who uses IDEs on Mac that we just hide (important: we hide and don't minimize) the window.

I think @vancura is right. It's not about running in background for some one time operation (i.e. build a project in our case, or copy a file in case of a file manager) but for continous activity in the background (like music which doesn't stop on its own). Email is something inbetween, you don't want to quit the app if you close it, cause you want to receive notification (and continously receive emails).

In case of an IDE you usually don't want to exit it, but I actually have NEVER ever used the close button, so I never noticed that we just hide the window, which felt weird at the first sight. Since all the other IDEs quit on Mac, and since it's what VS users (Windows) would expect, I'd say that we really change that behaviour.

Alternative for discussion: we minimize (with animation) or disable/remove the X button.

@sevoku Xcode doesn't quit when you close the window, it just closes the window.

The problem is that people close the window expecting it to be closed, but then when they click the app again they discover that is was just minimised, which is just weird.

We only support one window, so our behaviour on Close should IMO just be quit.

Converting to a multiple window model would be impossible for us as we've got so much code that expects a single main window, but it might be possible to support closing the main window, keeping the app running so the menubar is still operational, and clicking on the icon would bring the window back to the start screen again

@sevoku Xcode doesn't quit when you close the window, it just closes the window.

right, it doesn't quit, because they support multiple project windows at the same time, but we don't. Closing the main Xcode window will also close the project which is loaded there.

[...] but it might be possible to support closing the main window, keeping the app running so the menubar is still operational, and clicking on the icon would bring the window back to the start screen again

so instead of quitting we could just close the current solution and minimize the main window. sounds like a good compromise. @slluis ?

We need to find out what's the right behavior for an application like VSMac. I'm not against changing the behavior, but I want to make sure we do the right thing because it is an important change and it may have a big impact in our users. @mhutch what's your take on this? you wrote the original code.

I'm not sure. IIRC this was a quick attempt at making it feel "more Mac-like" while being constrained to a single window. As folks say, it seems somewhat weird, but I'm not sure closing is any less weird.

I think the problem is that we're already doing the fundamentally wrong thing for an app of this kind by not having document windows, and this is just fallout from that.