This thread could seems a bit curious to users so I'll describe what I want to see here :

- Some things you don't like in the design, that you could "live with" but not necessarily hard to fix it, like : why Loaders don't use the singleton pattern ? Or why do I have to have 5 lines of code to change the color of an object (or even more lines of code if you want scenegraph traversal !)

TransformGroup/Transform3D: Make Transform3D being an interface with only the getMatrix4f() method and add some implementations for translation / rotation / scale

BranchGroup: extend the BranchGroup class to RootBranchgroup with a contructor taking a projection policy and change the View class to take only RootBranchGroup instances and render depending on the given projection policy. And guerantee that its children are rendered in the added order (OrderedGroup could then be eliminated)

Scene/SceneBase: Change the Scene interface and SceneBase implementation to not return arrays in all the getters, but Vectors/HashMaps/etc. and let the SceneBase extend TransformGroup. Add a constructor with a desired size to SceneBase doing what GenericLoader does.

Generics: Review all the code to eliminate all the unused private variables and make all classes use generics to avoid unneeded castings.

org.xith3d.geometry: Let all geometry helpers extend a GeometryBase class or implement a common interface.

org.xith3d.geometry: Add contructors to all geometry classes to take an instance of com.xith3d.Texture like I did for Quad

org.xith3d.geometry: Maybe we should consider renaming the package to org.xith3d.shapes, because that's what it really is.

Package reorganization: rename com.xith3d to org.xith3d in the core, spread some classes into subpackages of their current packages. We should offer a small java proggy to update code to the new hierarchy.

Split refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. [JDT Core/UI] (106207) [Theme: Scaling Up].

Eclipse 3.2 is announced to be release in late june (during the next days ).

This should make it possible for us to change a lot of things without worrying about people using the new version to be f**ked up So we are free to reform/improve the package hierarchy of xith.

Split refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. [JDT Core/UI] (106207) [Theme: Scaling Up].

Eclipse 3.2 is announced to be release in late june (during the next days ).

This should make it possible for us to change a lot of things without worrying about people using the new version to be f**ked up So we are free to reform/improve the package hierarchy of xith.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org