Remove carbon #1012
Remove carbon #1012
Conversation
|
lgtm. |
| // Therefore we strip any .exe filenames here so we don't attempt to create a new solution based on | ||
| // that name. | ||
|
|
||
| IdeApp.OpenFiles (e.Filenames.Where (filename => !filename.EndsWith (".exe")).Select ( |
There was a problem hiding this comment.
XS can open .exe files as a solution, so you can run and debug them. So exe files should not be filtered.
|
Ah, ok. I'll have a think how we can work around it then. |
|
@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? |
|
So this filters out /build/bin/MonoDevelop.exe but nothing else |
|
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: If you need to filter exe's, maybe you could ignore any file which is the same as the entry executable ( |
|
Oh, i just remembered that debugging MD inside MD is a fifth way... :P Either way, that should work! |
This patch removes the use of Carbon for ApplicationEvents in MacPlatform
iainx
force-pushed
the
remove-carbon
branch
2 times, most recently
from
294bec9 to
24c743f
Compare
|
@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 |
|
sweet :) |
| // that MonoDevelop.exe is the first filename to be passed when the app starts up | ||
| // Therefore we strip any filenames that match the assembly that we started from. | ||
| var entryAsm = Assembly.GetEntryAssembly (); | ||
| Console.WriteLine ("Current ass {0}", entryAsm.Location); |
There was a problem hiding this comment.
Some forgotten debug code.
cough.
When Mono applications are run from the commandline or from within XS itself, the Cocoa system parses argv, stripping the executable name and any option arguments and passes the rest of the arguments to OpenFiles. Unfortunately for mono applications (for example "mono-sgen MonoDevelop.exe") the executable name is interpreted as a filename and so OpenFiles receives it in the array. We solve this by ignoring any filename that matches the Entry Assembly's location
iainx
force-pushed
the
remove-carbon
branch
from
24c743f to
3b564db
Compare
|
Bump on this and #1065. |
|
What are we missing here? |
| @@ -326,82 +327,77 @@ void PatchGtkTheme () | |||
|
|
|||
| void GlobalSetup () | |||
| { | |||
| var appDelegate = (Xwt.Mac.AppDelegate)NSApplication.SharedApplication.Delegate; | |||
There was a problem hiding this comment.
Do we have to cast it to Xwt.Mac.AppDelegate or can we cast it to a plain NSApplicationDelegate?
There was a problem hiding this comment.
the Terminating, Unhidden, OpenUrl and OpenFilesRequest events are Xwt.Mac.AppDelegate events, not NSApplicationDelegate
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