Ensure CeylonFX class hierarchy mirrors JavaFX's starting with Node

[renatoathaydes]

Currently, there is a good amount of basic components which show that CeylonFX is not only viable, but an excellent option to write JavaFX applications entirely in code (as opposed to FXML+Java).

Allowing, or encouraging users to access the underlying JavaFX classes when CeylonFX does not provide a wrapper (although necessary to start with) has proven to be confusing and even ugly (however, it currently seems to be impossible to hide them completely, which may or may not be seen as a problem).

Therefore, all relevant classes in JavaFX, but most specially Node and its sub-classes (controls, layouts, shapes, text, etc.), need to be wrapped adequately to take full benefit of Ceylon's syntax and feel.

My plan is to, in order:

• implement Node (which will require the implementation of several minor 'config' parameters)
• Implement most layouts (based on the current VBox)
• Implement most controls (based on CheckBox)
• Implement most other things, like Shapes (see Rectangle), Paints (see Color), Text etc.

I believe that, given the prototypes which are already working (as of 2013/Dec/11), it's finally time to start on this.

Input from anyone interested in the future of this project is encouraged.

[ghost]

I believe that we shouldn't use FXML in CeylonFX. @gavinking has once said that Java depended too much on XML. Just stick to this current design (it's great) and maybe create an application that writes the interface code for you when CeylonFX is more or less complete.

[renatoathaydes]

@paper1111 this ticket has nothing to do with FXML... it's about creating the Ceylon interfaces for the underlying JavaFX components.

[ghost]

Ah I read it wrongly, you were saying opposed to FXML+Java