Complains about Xith3D 0.8

[Amos Wenger]

Post yours here so I/we know what to fix for 0.8.1

[Amos Wenger]

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 !)

- Some small bugs you noticed or integration problems

[Marvin Fröhlich]

ok. Then I will collect some things mentioned in previous threads:

• 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.

That's all for the moment.

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

I found this on eclipse.org: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html#JDT

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.

[Amos Wenger]

I found this on eclipse.org: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html#JDT

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.

Yeah and it seems like much people's using Eclipse with Xith3D.

[dcomes]

Is there a tag in CVS for 0.8 release?  If not can you guys make it part of your release procedure?

Thanks!

[Amos Wenger]

Is there a tag in CVS for 0.8 release?  If not can you guys make it part of your release procedure?

Thanks!

Well I must admit my CVS knowledge isn't as big as I would..

If you indicate me the procedure to follow I'll happily do that. (If I have the needed access rights, of course).