external script editor: what apps are allowed?

I made a little AppleScript app that allows me, from OSX, to open a C# script in Visual Studio (in a VMware).
Right now it works by dragging the script I want to open over the app (they call it a droplet).

But when I try to set it as my external script editor, Unity won't accept it (I select it and it just doesn't show up in the preferences).
So I'm guessing Unity's doing some sort of filtering, maybe they're a flag in the apps, and it only allows "text-apps" like TextEdit and TextMate... or something?

This is too bad cause the droplet works fine, if only Unity would run it...

 

Might it be that Unity doesn't recognize Windows running in VMWare and therefre can't even recognize a Windows app like Visual Studio?

 

...nope, I don't think that's what it is .

My app is an OSX app, and works ok in OSX.
It's just Unity that doesn't seem to accept it as a script editor.

EDIT: just to clarify, in a nutshell my OSX app creates a batch file (with the name of the C# script I want to open) in a folder accessible from the VMware, then sends a keystroke event to the VMware that opens a shortcut to this batch file.
But that's doesn't matter, this is VMware-side, all I need is to run my app OSX-side. So really, what I'm saying is unnecessary and doesn't clarify anything. Please unread it, people.

 

Oops, my mistake then.

 

Most likely you need to edit the droplet app's Info.plist to tell the Finder that it can handle text files. Right click the droplet, choose Show Package Contents, then navigate to Contents/Info.plist. You might need Apple's Xcode Developer Tools installed to open it if the file has been saved in binary mode, but if it's a text file you can open it with whatever text editor you want.

You'll need to add this structure to the plist, or merge it in with whatever it has in the first place:

Code (csharp):

1.  
2. <key>CFBundleDocumentTypes</key>
3. <array>
4.     <dict>
5.         <key>CFBundleTypeExtensions</key>
6.         <array>
7.             <string>txt</string>
8.             <string>text</string>
9.             <string>*</string>
10.         </array>
11.         <key>CFBundleTypeIconFile</key>
12.         <string>txt.icns</string>
13.         <key>CFBundleTypeMIMETypes</key>
14.         <array>
15.             <string>text/plain</string>
16.         </array>
17.         <key>CFBundleTypeName</key>
18.         <string>NSStringPboardType</string>
19.         <key>CFBundleTypeOSTypes</key>
20.         <array>
21.             <string>****</string>
22.         </array>
23.         <key>CFBundleTypeRole</key>
24.         <string>Editor</string>
25.     </dict>
26.     <dict>
27.         <key>CFBundleTypeName</key>
28.         <string>Apple SimpleText document</string>
29.         <key>CFBundleTypeOSTypes</key>
30.         <array>
31.             <string>TEXT</string>
32.             <string>sEXT</string>
33.             <string>ttro</string>
34.         </array>
35.         <key>CFBundleTypeRole</key>
36.         <string>Editor</string>
37.     </dict>
38. </array>
39.  

That stuff goes inside the outermost <dict> element. Incidentally, I stole that from Apple's TextEdit.app's Info.plist. You could compare your app's plist with that (and with the plists of other apps) to see what it's supposed to look like.

The next fun bit is that the OS is notoriously bad at noticing when an app's Info.plist has changed. You may need to duplicate the app and delete the original, or even restart the computer, before it'll work properly.

If you get stuck, Apple has documentation on how Info.plists work.

If you're really unlucky, the Show Package Contents menu item won't appear because the droplet is a single file instead of an application bundle. In that case, it's still possible to have it recognised as a text editor, but it becomes quite a bit more difficult to set it up correctly. I'll let you try the way I described above before attempting to describe the hard way.

 

Ben: I don't know what limits are in place for external editors myself, but I'll see what info I can find and share that here when I have it (or get someone who does know to post up themselves).

 

Thanks for the info Joachim!

 

Thanks for all your answers !

To NCarter: ... too bad, my app is only one file, no contents and no plist. It does have the .app extension, and it shows up as a file seen from Windows, not a directory as other apps (=> no "show contents" menu item).

To Joachim: I too thought that Unity would just accept any app and let it do whatever it wanted... but it still doesn't accept this one, I double and triple-checked.
My app is an AppleScript compiled as an app (which I suspect is Apple's fancy term for "changing the extension from .scpt to .app")... don't know if that counts as a "true" app...

 

Ben: When you use VMWare in "Unity" mode, it creates .app links in the Virtual Machine folder and puts a link to those in the Mac OS Dock.
What you can do, is pull the Visual Studio link out to the desktop and reuse it later. It seems to work even when you switch to other modes.

Just do Show Contents on your Virtual Machine, and the .app for VS is in the Applications folders. I don't know if this will work, but good luck
Heres what I mean:

 

It is a real app, but it's an OS9 style app, so you just get a single file. However, you can save your scripts as an application bundle if you prefer to. It's one of the file format options in the save dialog in the Script Editor.

 

To shaun: neat trick!! But unfortunately it only opens the app, doesn't seem to pass the script to open as parameter.

That did the trick, thanks ! So apparently Unity doesn't accept OS9 apps.

So I got Unity to fire my app, but now it doesn't work though, probably because the script to open is passed as an argument in a different way as the droplet way, for which I handle the on open (list_of_dropped_items) event.
I probably need to handle a different event... or go for the external editor apple event Joachim mentioned... you seem to know more about AppleScript than I do, so if you have an idea, I'm all ears .

 

Check this out :
http://www.activestate.com/Products/komodo_ide/
http://www.activestate.com/Products/komodo_edit/

This is very flexible.

If you code javascript it has intellisence built in.
If you code c#, you hack up debugger by
installing mono and using mcs to compile c# externally from unity.

you can access the command line very easy, so you can compile anything
c#, c++ etc

you can have fink on tap
see http://www.finkproject.org/

Also it has custom language support.
So if you into creating custom
background syntax checking, syntax coloring , auto completion
you can.

you have built in perl, python and tcl.
so you can do some quick file system stuff or auto code gen
ActiveState also ships
Perl Dev Kit 7 to create .NET assemblies from Perl
theoretically opening up the CPAN libs
http://www.cpan.org/

i have tried the Perl to .NET thing yet, but it looks doable

Also has a XML DOM viewer build in

i think this is the best option around.
Because you can hack up anything you like

 

Thanks for the info, I didn't know Komodo, I only tried Eclipse, which was kinda cool but more limited to Java.

It seems a lot of work to configure though to get all the features that I'm used to, and I'm very happy with VS, plus I know it so I'm fast with it.
But does it really have everything, all the advanced stuff like refactoring, autocompletion inline doc for the whole .NET framework?

Only 2 things could make me consider switching:

• using Unity for compiling seems neat because right now I often double-compile, once in VS to check my code, then one auto-compile when I switch back to Unity. Thanksfully I have a MacPro so it doesn't slow me down much, but still it's not optimum.
• one thing I really really miss from when I was doing ASP.NET is debugging. VS's debugger is so powerful, you can see so much info so fast... but you can't connect it to Unity, so something while scripting I feel blind as mole!
  Can you debug C# with Komodo, while Unity is running?

 

I know I'm resurrecting a topic... But the information still seems to be valid

This information and the workaround for Sublime Text described on the Wiki seem contradictory! I'm asking this in light of using Visual Studio Code as an external script editor. VSCode implemented command line arguments for opening files at a specific line number, specifically to aid Unity users. On a Mac, though, it isn't possible to pass these command line arguments from the preferences window.

 

I have to agree with this. What does that link to the codingmonkeys page even mean? The wiki states the line and column arguments are simply passed through, but I've verified that they certainly are not passing when calling an arbitrary .app from Unity 5.0.

So what's the secret sauce, is it even possible to simply pass line/column values on OSX currently?

 

i'm using Pluma on GNU/Linux, it works perfectly fine!