Custom C# GUI:

Advantages
 Qt makes it impossible to create a proper docking system but I can't find top-most window
 In general such simple operations are proving problematic
 I will need to build a system working with C# anyway at one point
 Qt is possibly slow (example is the Console and List widget)
 C# is much easier to write

Disadvantages
 I need to implement Camelot2D and CamelotGUI system
   - These systems need to be designed properly and I will likely need to re-design some of engine systems if I find them lacking and they haven't been properly tested
 Multiplatform management of windows might be problematic (However it might get handled by Mono decently?)
 I will need to create a C# interface for the system (Need to do this anyway)
 I need many controls I wouldn't need for a game 
 


Camelot2D
 - Check out Ogre and possibly Torque to see how they implement it
 - Support for sprites
 - Support for text
 - Optimized rendering?
  - Allow to place sprites into pages, which then get texture atlased
  - Before rendering dynamically batch the mesh so number of 2D draw calls is reduced
 - Animated sprites?

CamelotGUI
 - Label
 - Text field
  - Int field, float field?
 - Text area
 - Scroll area (Vert/Horz)
 - Button
 - Checkbox
 - Radio button
 - Tree view
 - List view

 - Allow Unity-like layout based system, only with callbacks

 - All controls must be fully skinnable


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

 CamelotGUI
  - Traditional UI with buttons, lists, text fields, etc.
  - Easy to use for desiging the editor and debugging
  - See the UML diagram (GUIClassDiagram.violet) for description

 Camelot2D
  - System meant for 2D games and proper in-game UIs
  - Proper support for all kinds of animation
  - Together with helpful controls for rendering text, input boxes, etc.

  Maybe it would be better to somewhat combine these two after all, to avoid re-doing a lot of code?
   - All UI elements can reference a GUITexture instead of a texture. GUITextures can be pre-processed into a texture atlas before use
     so that UI can be easily dynamically batched. 
   - This way both GUI types can use GameObjects for rendering and share the same types
   - Rendering is handled by some parent GUI class, not individual elements. So that the GUI can be properly batched
   - Need layers that will allow me to filter GameObjects for rendering camera per camera
   - Need a flag that will hide Editor elements in Hierarchy, and also prevent saving them with scene.
   - CamelotCore should in no way depend on CamelotGUI or Camelot2D (if I decide to split them into two classes)

Start just with Camelot2D
 - Text rendering
 - Sprite rendering (+ batching and similar)

Then CamelotGUI providing basic controls like Labels, Buttons, TextFields

Then CamelotEditor providing its own implementation of CamelotGUI


FIRST STEP:
 - Camelot2D, Freetype and fonts. See Ogre::Font

  Support both ttf and image fonts? Image fonts would get loaded from an texture + .xml file and could be used made
   - Fonts should always be defined through an image + FontDesc
   - Freetype importer would just generate the image and FontDesc automatically?