BansheeEngine/CSharpWrap.txt

Classes that need C# wrappers:
Math (Instead of a wrapper create actual C# classes, but which map 1-1 with C++ code so we can move them through C++/C# boundaries):
 -Vector2
 -Vector3
 -Vector4
 -Matrix3
 -Matrix4
 -Quaternion
 -Rect
 -Int2
 -Color

Resources:
 - Mesh
 - Texture
 - Font
 - Material
  - GpuProgram
  - Technique
  - Shader
  - DepthStencil/Blend/Rasterizer/Sampler state

Core objects:
 - RenderTarget
  - RenderWindow
  - RenderTexture
  - MultiRenderTexture
 - SceneObject
 - Component
  - plus specific components Camera, Renderable, maybe others
  - (later ofc ability to derive custom C# components)

GUI:
 - EditorWindow
 - GUIWidget
 - GUILabel/GUIButton/GUIToggle/GUIInputBox/GUITexture...
 - GUILayoutX/GUILayoutY/GUILayoutOptions
 - GUISkin/GUIElementStyle

Systems:
 - Resources
 - Importer
 - Application (startUp/shutDown)
 - Cursor
 - Debug
 - Input
 - Time

 -----------------

// TODO - I might need to call this
 retval = mono_jit_exec (domain, assembly, argc - 1, argv + 1);
to call a Main function in the assembly

 -----------------

For EditorWindow, add a new class in BansheeEditor, which pretty much does the job of  EditorWidget::open
 - Except it creates an empty widget. (It will also create a window, but in C++ code)
 - All the window docking/undocking moving/resizing is done in C++
 - EditorWindow only has a reference to EditorWidget

 -----------------

 Implementation steps:
 - Get EditorApplication finished and make the main window open from C#
 - Add support for Resources
   - Importer - Likely invisible for outside world
   - Resources.Save/Load - Will likely need some kind of an AssetManager for all imported assets
   - Texture, Mesh, Font, Shader, Material
     - Before this I will also probably require all the basic classes like Vector3, etc.
 - Emulate current CamelotClient tests in C#

 -----------------

 But which ones will I need initially?
  - [EditorApplication] - Entry point. Creates a MainEditorWindow
  - [EditorWindow] (Scene, Project, Hierarchy, etc.)
   - show()/hide()
  - [MainEditorWindow]
   - Slight variation of EditorWindow as there can be only one of them
   - Contains [TitleBar], [DockManager]
  - When adding GUI elements I need to make it easy to add game GUI elements,
    but also make a distinction and make it possible to add editor GUI elements.
	- Each EditorWindow contains a [GUIWidget] (created by default)
	  - This GUIWIdget is created specially with EditorWindow as its target
	- GUIWidget is also a Component which can be used for rendering to Game view
	  - All game GUIWidgets are created with Game render target as their target
  - [GameObject], [Component]
    - Need something to add GUIWidget to
  - I need to have [Application] running within EditorApplication
    - So when I remove EditorApplication everything runs as normal
	- How to make the distinction?
	  - Application needs to render to RenderTarget when in editor, and have its own window when standalone
	   - When in Editor, EditorApplication will call application and tell it to create a render target
	   - When published I will have a Game class, which will also call Application and run it in a window
	  - Certain components should only exists in editor (Like Scene camera, gizmos and etc.)
	   - Add a flag to GameObjects like in Unity, that can hide the object in Hierarchy, or make it not save
	   - Editor objects would be hidden and would not save with the level, which would make publishing work
  - GUIWidget
    - [GUILayoutX], [GUILayoutY], [GUIArea], [GUISpace], [GUIFlexibleSpace]
	- [GUIElement]
	  - [GUILabel], [GUIButton], etc.
	- TODO: GUISkin? - Will I need to create interface for textures and resource loading/importing as well? Probably
  
  ----------------

Eventually make all math classes templates that work on both doubles and floats. (Very low priority)

----------------------------

EditorGUI - NOT a component
 - Internally just a GUIWidget
 - has AddArea method
 - has main field that points to main Layout
 - shares interface with "GUI", which is used for main game window
 - has a reference to GUISkin. Default is GUISkin.main

GUIArea
 - has layout field
 - has AddLayoutX, AddLayoutY

GUILayout
 - has AddButton, AddLabel, AddLayoutX, AddLayoutY

GUIButton, GUILabel
 - Require GUILayoutOptions, GUIElementStyle upon construction
 - Have Destroy() methods

GUIElementStyle
 - Requires font
 - Requires SpriteTexture
 - Create DUMMY font and texture classes for now

GUISkin 
 - Has pointers to GUIElementStyles for button, label, etc. plus support for custom styles using GetStyle(name), SetStyle(name)

Immediate:
 - Implement ScriptGUIBase
 - Delete: GUIWidget and ScriptGUIWidget

When loading resources I need to be able to load both project resources and engine ones. 
 - BuiltinResources can be used for accessing default resources like GUI skin textures and similar
 - They're all loaded from a special folder that is set in EditorApplication

Should I make sprite texture a resource?
 - Quite probably, and will need to replace any Ptr references with handle references. I want the user
   to be able to reference the resource in multiple locations and then he can easily edit the SpriteTexture as needed.

ScriptGUILabel currently accepts a WString, while it should be accepting a HString. Check BsScriptGUILabel

 BsApplication::getPrimaryViewport is not implemented

Reconsider making scripts a static library
 - The scripts would only have one external header that allows you to start the script engine and load assemblies
 - So BansheeEngine script library would be dependant on BansheeEngine
 - BansheeEditor script library would be dependant on BansheeEditor, BansheEngine and BansheeEngineScript
 - Maybe even make them .dlls? Then BansheeEngine and bansheeeditor doesn't need to know about their includes

IGNORE RESOURCES FOR NOW. When building the GUI make sure that they all temporarily use the native skin
 - Later implement GUIBase.skin (and actually implement GUISkin because it's just a dummy for now)


----------------------------

  I want my .exe to be native. Internally it will call MBansheeEngine and MBansheeEditor.

This will allow me to debug and start C++ as usual.

 -----------------

 Notes:
  - I will need RequireComponent[] attribute. This attribute should automatically add the specified class to the wanted
    GameObject. This is useful if you suddenly decide your class is now dependant on another, but you would otherwise have to manually
	go through all instances of that GameObject in scene and add the required component.
	  - HOWEVER, a more generic way of doing this (maybe using prefabs) would be useful. Because what happens when a class suddenly becomes
	    dependant on a resource, or a specific instance of a class? In that case we cannot use RequireComponent.
  - Use FrameUpdate[QueueIdx], OnCreate[QueueIdx], OnDestroy[QueueIdx] attributes to signify to the scripting system when to execute
    certain methods. QueueIdx allows you to specify the order in which these methods will be called. In Unity you have Awake and Start methods
	for initialization, but here you may just specify OnCreate[0] and OnCreate[1].
	  - I will likely need C++ equivalents of these queues because C++ components will also require such ordering.