mono
Remove carbon
Second pass at removing the use of Carbon for the ApplicationEvents, instead relying on the Cocoa application delegate methods instead.
Fixes the issue from the previous attempt that starting MonoDevelop from the command line or from inside itself would create a blank MonoDevelop solution in the build/bin directory due to Cocoa interpreting the MonoDevelop.exe from the command line mono-sgen MonoDevelop.exe as a filename
@slluis filtering .exe files in the OpenFiles event from the AppDelegate doesn't break loading .exe files from the Open File dialog. The only way a .exe file is passed to the OpenFiles delegate is when running from the command line as make run or running from inside of MD itself.
Would you prefer that I just filter out MonoDevelop.exe here instead of *.exe?
Is this problem specific to starting MD using mono-sgen? doesn't this happen when running from an app bundle?
There are a few ways MD can be started on macos:
make run-sgen in a local build which turns into a mono-sgen monodevelop.exe call
make run-boehm in a local build which turns into a mono-boehm monodevelop.exe call.
make run which builds the native launcher and turns into a ./monodevelop call (like an app bundle)
open MonoDevelop.app or double click the app bundle
If you need to filter exe's, maybe you could ignore any file which is the same as the entry executable ( Assembly.GetEntryAssembly () ). That should give you the behaviour you need without hardcoding specific names or always ignoring all .exe files. As long as the right thing happens in the above 4 cases then we should be OK
Oh, i just remembered that debugging MD inside MD is a fifth way... :P Either way, that should work!
@alanmcgovern yup, using the entry assembly location works. This was only an issue for when we run MD via make run-sgen/boehm or from debugging inside MD itself. The other methods were not affected