There's (at least) one thing I want to know : what is the toolkit exactly intented to be ?As it is actually, it contains Geometry classes, Terrain generation utils, and several other things I forget here (collision detection maybe).But here I am : I have made several util classes for my projet using Xith, among them :

Transform, which is a fusion of TransformGroup and Transform3D. You can call the transform(int type, Tuple3f transform) function to adjust the transformation.

Another set of primitives, that are using the primitive classes of the Xith-tk but are based on my small geometry library (gymli)

A class named BlackBoard, with functions drawSegment(), drawDot(), drawCircle(), all with different width, colors, and all that stuff, with erase() function

And I plan not to stop here. Currently it's on an SVN server, under a project code-named Globe (GL = graphic library).Now is it possible to integrate it in the Xith tk ?Yes, because I have the Developer access of the repository.But it depends on Gymli (the geometry and math library) and so I cannot make another dependency of the xith-tk.On the other hand you may agree, according to what can be read in XithToolkitGuidelines, that these tools are to be placed in the xith-tk.So when I created these classes I didn't know what to do, and that's why I decided to put it in another library, on top of Xith3D. I don't override any base class and the functionning of my engine is the same as any Xith app.Now with jaakko777 we're about to start the SGS (Small Gui System) project for Xith. We've almost decided to put it in the Xith toolkit, however I think it would gain more visibility if it was a separate project.Here are the questions I have, I would be pleased to have your opinion on it.

Well I'm certainly still a nOOb around here but still I dare to say that the stuff in xith-tk should not be depending on any extra libraries/APIs.In my opinion they should be allowed only to depend on other xith-tk packages and the standard Java API (like the swingui for example).Ofcourse also jogl and lwjgl as xith itself depends on them!

Im not sure if this is what you asked, but thats my opinion about what should go there and what not...

As long as each component declares its dependencies (and preferably gives versions of them) does it really matter? Wouldn't want to deter people from contributing to the toolkit because they can't use a certain library - surely its up to the end developer to make the decision whether they're happy to take on the dependencies or not (as with using Xith).

WRT to adding the UI to the TK package - it really does make sense - one place to find everything Xith related is much more useful than scouring the web for possibilities. It also makes it easier to move it into the core if and when its seen fit - since licensing will already be sorted.

There's (at least) one thing I want to know : what is the toolkit exactly intented to be ?

Here's some of the reasons for its existance:

1. to coordinate and provide resources for Xith3D tool development2. to create a central repository for Xith3D tools so they are easily accessable3. to allow developers to use org.odejava.* packages with the confidance that they will be kept up to date with Xith3D API changes, that they are community supported and will always be available. Such packages are also licensed-alike with Xith3D, so there won't be any nasty surprises.

This doesn't mean a package will always be maintained - but when Xith3D changes are made, corresponding changes will be made in the Toolkit (not least because both are on my Eclipse build path so I instantly see when a change to Xith3D breaks something in the TK.

Quote

As it is actually, it contains Geometry classes, Terrain generation utils, and several other things I forget here (collision detection maybe).

The main reasons why these arn't in the core is simply that they don't need to be. By being in the toolkit, it is much easier for people to contriubte to them and also easily cut them out from their project prior to release if they don't use them.

Quote

But here I am : I have made several util classes for my projet using Xith, among them :

Transform, which is a fusion of TransformGroup and Transform3D. You can call the transform(int type, Tuple3f transform) function to adjust the transformation.

Another set of primitives, that are using the primitive classes of the Xith-tk but are based on my small geometry library (gymli)

A class named BlackBoard, with functions drawSegment(), drawDot(), drawCircle(), all with different width, colors, and all that stuff, with erase() function

And I plan not to stop here. Currently it's on an SVN server, under a project code-named Globe (GL = graphic library).Now is it possible to integrate it in the Xith tk ?

Definitally, please put them in

Quote

Yes, because I have the Developer access of the repository.But it depends on Gymli (the geometry and math library) and so I cannot make another dependency of the xith-tk.On the other hand you may agree, according to what can be read in XithToolkitGuidelines, that these tools are to be placed in the xith-tk.So when I created these classes I didn't know what to do, and that's why I decided to put it in another library, on top of Xith3D. I don't override any base class and the functionning of my engine is the same as any Xith app.

Dependancies are definitally allowed in the Xith-TK project. Dependancies additional to those of Xith3D (such as commons-logging, vecmath, etc) MUST be specified in the package level javadocs including dependancies on other Xith-TK tools (the idea being that people can strip out the parts of the TK they don't need when releasing).

There aren't specific guidelines on 3rd party dependancies for tools, though being open source and readily available is quite important and licensed alike (BSD) is very desirable.

The TK Governance page states on dependancies: Package-level javadoc's MUST exist for each tool and contain a short description of the tool, the author(s) names and have any dependencies (other than that of Xith3D core itself) listed.andThe addition of third-party libraries are permitted within reason and should be placed in the third-party directory (it is advised to check with the community first)

Quote

Now with jaakko777 we're about to start the SGS (Small Gui System) project for Xith. We've almost decided to put it in the Xith toolkit, however I think it would gain more visibility if it was a separate project.Here are the questions I have, I would be pleased to have your opinion on it.

I agree with Kev on this, it just makes sense to have it there. I feel like it will gain more visibility if it's there because the Javadocs are with the rest on xith.org, and all developers get the .jar. If more visibility is what you want, you create your own web site for the project, or a well maintained wiki-entry on xith.org. If this project succeeds where other GUI efforts have failed and comes through with the goods, it will be a very valuable addition to Xith3D. Lets wait till that happens, but some of the things can improve visibility include a tutorial in the GSG, screenshots on xith.org, etc...

I think we will end up with a 10 Mo Xith toolkit that everyone needs and yet nobody needs everything that's into it.

We can make it more modular if this ever happens. Right now the decision was made not to break the packages up because it would create many more .jar files for people to include, etc. We figured that when someone is ready to release, they will take the time to cut out what they don't need - if size is important. Currently the only division is for the "xith-demos.jar" file, being that the demos shouldn't be included in most projects, and can contain image data, etc.

There's (at least) one thing I want to know : what is the toolkit exactly intented to be ?

Here's some of the reasons for its existance:

1. to coordinate and provide resources for Xith3D tool development2. to create a central repository for Xith3D tools so they are easily accessable3. to allow developers to use org.odejava.* packages with the confidance that they will be kept up to date with Xith3D API changes, that they are community supported and will always be available. Such packages are also licensed-alike with Xith3D, so there won't be any nasty surprises.

This doesn't mean a package will always be maintained - but when Xith3D changes are made, corresponding changes will be made in the Toolkit (not least because both are on my Eclipse build path so I instantly see when a change to Xith3D breaks something in the TK.

But here I am : I have made several util classes for my projet using Xith...Now is it possible to integrate it in the Xith tk ?

Definitally, please put them in

Okay, I'll do so. I think the blackboard should be part of the UI package.Note I originally thought my "Transform" class was "sacrilegious" (because not following the standard api way) and then I didn't intended to put it in the tk. But however that may be, I think it's really more practical than using two different classes. In fact, it reduce transformation code from 5 lines to 2 ! And it's much more clear. But you'll see all the applications in the javadoc

I agree with you for the last part of your message.

So I can put it in the Xith-tk. I promise, one more constructive message on this board and I go for it. (You probably don't imagine how many things I have to do ! Err.. ah yes you code too.. okay so you know )

Oh and about the screenshots on Xith website, we probably should do a repository of projects using Xith, with screenshots and links to the homepages. That would be great. (Although we need somebody managing that).

I think the Toolkit is espacially useful for "util classes" that are relatively independent on a specific tool/project, but aren't big enough to make an own project. I think, only if your tool starts to get over about 50 classes and several packages, it might be worth a thought to have an extra project for it. So integrate it into the xith-tk!!

Quote

Oh and about the screenshots on Xith website, we probably should do a repository of projects using Xith, with screenshots and links to the homepages. That would be great. (Although we need somebody managing that).

Yeah that idea is good - mmh couldn't we simply make a page in the www part of the xith-tk, that list all those projects. If I'm not wrong every user with developer-acess on the xith-tk has a right to change that, so it would be an easy thing to add xith-using projects to that list. We then simply could show that page on the xith3d homepage.I think this would be the simplest way of dealing with that.

For the toolkit, yes ok I see. Now I realize the primitives I made weren't so useful, I can use directly Xith's ones, and the ones which depended on Gymli I can put them in Gymli directly (or in Gymli-xith3d, as it has been made for Odejava-xith3d).

For the list of projects, yes we could make a page in the www part of the xith-tk, what I don't know is how to make a menu entry so the visitors are actually able to see this page...

i also use a eclipse project to use the toolkit, but the ant way doesn't work for me either

i just had some time and worked through the errors i get:

xith-tk/src/org/xith3d/test/jcd/Lesson37.java:52: warning: unmappable character for encoding UTF8-> change those characters ( they are just in comments )

xith-tk/src/org/xith3d/test/jcd/MouseRotation.java:109:org.xith3d.test.jcd.MouseRotation.Mouse is not abstract and does not override abstract method newX(int) in net.jtank.input.MouseListener-> the hial version that is used is deprecated, there is a new version under xith-tk/libs (the one under xith-tk/third-party is used) so this is fixed by moving the one from libs to third-party overwriting the old one

after fixing this stuff the toolkit compiles with no further problems ( but i don't know if MouseRotation will work )

just another thought:wouldn't it be useful to have several build targets for all contributions to the toolkit and one that just takes everything that got compiled and make a jarfile from that?would be good for those who just need some parts of the toolkit (eg: ant geometry; ant build-stripped-jar; ... so you have a jar file that just includes the geometry stuff )

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