As the title says.
I use a couple of scripts that extend the Unity editor functionality, like SceneAsset class or TagSelector attribute, but now I just realized I can't build my project because of them and now I have to delete all of these and replace them with normal string and fill it myself, which I was avoiding until now.
Do I use these classes only for development? I know I can use #if UNITY_EDITOR #endif so part of the code will only work if built via Unity Editor, but in my case, this seems ugly because I want to declare fields via the inspector. Do I have to declare multiple fields for the same thing and separate the usage or is it possible to make two versions for one field so I don't have to change the code?
You can't have anything using UnityEditor in a build since this namespace is completely stripped of.
You only use it so you can implement editor scripts that simply only extend the functionality of the Unity Editor itself ... custom Inspectors/Windows etc.
Make sure you
Either put these in folders called Editor! these are excluded from the build automatically
Or use the pre-processors as you mentioned
Serialized fields should be used for both, editor and build (otherwise you will always get some warning about mismatching serialization layouts). If you need them for the editor, just keep them for the build as well even if they are not really of use there - they don't hurt and nobody will see them anyway.
Related
I'm developing an extension in VS Code to add language support for OpenSCAD (Script-based 3D modeling program). Currently, I have been working on a way to open / preview a file in OpenSCAD from VS Code, which I have been able to do successfully using my own preview manager.
My issue is that I want to add configurable naming formats when exporting an OpenSCAD file that use environment variables similar to those used in the tasks.json file. More info can be found here: https://code.visualstudio.com/docs/editor/variables-reference. As an example, taking the file test.scad and the export configuration ${fileBasenameNoExtension}.stl would export to the file test.stl.
Additionally, I want to add a custom variable, ${#} that would evaluate after all other variables as a unique version number to avoid duplicate exported files. Using the example file: test.scad and the export configuration, ${fileBasenameNoExtension}_${#}.stl, the extension would export to the file test_1.stl for the first time. Then, seeing that test_1.stl exists, it would export to test_2.stl, and so on. I implement similar functionality in all of my exporting utilities, so it is important I can implement it here.
Now that the intro is done, on to the actual question: To anyone who knows more about the VS Code API than I do, in order to best get the functionality described above, should I implement environment variable evaluation into my custom preview manager or reimplement the preview manager I have using tasks? Because I have already implemented my own preview manager that I am happy with, I would prefer to do the former. However, I have been unable to find any functions in the VS Code API that will evaluate the environment variables in a string. Is there a typescript function to evaluate environment variables in the API that I have missed?
If re-implementing this functionality using tasks is a better way to achieve my goal, would I have to sacrifice the control I have in my preview manager, such as being able to selectively kill open previews and dispalying active exports?
Or, is there a compromise that could use all of the power from tasks without losing any functionality I've already developed?
Link to branch of my extension's repository: https://github.com/Antyos/vscode-openscad/tree/PreviewModel
Goal:
I want to define groovy classes in .groovy files as part of a package, but without ever needing to compile them. Then, I want to define groovy scripts in the same package, import the class definitions from the nearby .groovy files, and execute the script... all without compilation.
Problem,
This appears to be possible using GroovyClassLoader() (and several people have posted how-tos). However, the problem I have that nobody else seems to reference is that this strategy means that content assist will never be able to identify your classes and methods, and your code will be full of underlines, and receive no error checking.
You might say "Thats just a side effect of using such a dynamic feature, how would eclipse be able to know?", but consider the following:
As I was building my project, I was creating the scripts and the classes in the package just like normal a program. When I add my import statements for my custom classes, Eclipse recognizes everything and content assist is happy. However, despite content assist being satisfied, it hits a snag when I try to execute a script because eclipse returns: unable to resolve class (presumably because it's still only a groovy file, and not compiled to a class file).
So, I looked around and it looks like I have to comment out the import statement, and then use groovyclassloader to parse the groovy file instead. However, this has the negative side effect of breaking content assist.
Question: Are my conclusions above all basically correct?
Suggestion: Is there any known way to have content-assist work along-side with GroovyClassLoader? Maybe some way to tell it to ignore failed imports or something?
It turns out this was a problem with the way I had configured my classpath. Once I had my folder structure consistent with the package structure, eclipse found my class files and was able to import the classes.
When writting RCP Plug-ins it often happens that i need to declare and reference IDs in the extension specification (i.e. in the plugin.xml) and also in my java code. When I change one of those, I also have to change the duplicate.
I'm not sure if the problem is already that the same IDs must be used in the code and the plug-in declaration, but thats how the eclipse plug-in templates do it. If that's the root of the problem: how to prevent it?
If it's the correct way, to declare and reference IDs in the plugin.xml and in the java code: how to prevent that code dulication?
Also inside the plugin.xml there is something that may be regarded as duplication: ID definitions and the references pointing at them. If I change the definition, all references have to be updated. One could do that by simply replacing all text-occurence. But I normally edit the plugin.xml in the Plug-in Manifest Editor (i.e. in the forms, not in the plain text XML). Is there a way to refactor the IDs from inside the forms, without touching the plain text xml and without the fault prone approach of simple text replacement?
If you are referring to properties such as Bundle-SymbolicName then you should think of it as a package name, i.e something that shouldn't change at all.
Several of the other fields can very easily be externalized to strings, this is to simplify translations. See this help page. A wizard is available on the overview tab in the manifest editor.
I have to do an enhancement to an eclipse application and create a diff-viewer which compares two files(.blx) format. But, the application as such doesn't have the org.eclipse.compare bundle in its target platform. Now, if I include the bundle, the option Compare With comes with any pair of selections.
So, Instead of using extension points, I included the source of org.eclipse.compare in my plugin. But, Now I don't know if I should also create the extension points and use the same.
I am unable to create the structure compare pane.
You are in for a fair amount of work (I'm working on a similar thing now). Start with the Compare documentation and read it carefully. Depending on how close what you are doing is to a text compare, you might be able to get away with simply subclassing things and using the extension points. However, if you have other requirements (non-textual) then it's likely that you will need to copy some of the code.
I don't recommend that you use the source of the plugin directly however. Just make sure you add it to your application as a dependency.
Are there any tools out there for Objective-C / Xcode? Something that can do one or more of the following:
Detect unused imports
Auto-synthesize properties
Autogenerate dealloc method from retained properties
Provide method stubs for interface
-Detect unused imports
Not sure of anything that checks for dead imports.
-Auto-synthesize properties
-Autogenerate dealloc method from retained properties
User Scripts work quite well to do this inside Xcode, you can also use a program like Acessorizer as mentioned but it pastes something onto the clipboard for you to paste.
-Provide method stubs for interface
type "init" just after #implementation, and type Control-. (period).
These are user macros (not scripts), and you can easily define your own. Note they have placeholders that you can use tab to jump to the bits to fill in.
You want to look at Kevin Callahan's Accessorizer, which can do several of the things you request and more. The Google Toolbox for Mac also includes an Xcode plugin that can remove whitespace and a few other things.
You could probably do something with AppleScript or another scripting language, called via AppleScript, to operate on method or header files.
If you want static analysis, Clang is built in to all recent releases. None of what you've described has anything to do with static analysis, however.