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.
Hmm… good points there, but then we are talking about features that will never end up in the xith core.
Well on the other hand, why would they need to…
I think we will end up with a 10 Mo Xith toolkit that everyone needs and yet nobody needs everything that’s into it.
Here’s how I think it should be (much more modular) :
Core : Bare minimum (as it is now)
Toolkit : Tools that aren’t big enough to take place in a separate library (Transform class I’ve made, Primitives, Model loaders, Terrain generation)(Note that collision detection should be removed, it’s definitely deprecated…)
Separate lib : Guild (Graphical User Interface Library for quick Development)
[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:25980"]
There’s (at least) one thing I want to know : what is the toolkit exactly intented to be ?
[/quote]
Here’s some of the reasons for its existance:
to coordinate and provide resources for Xith3D tool development
to create a central repository for Xith3D tools so they are easily accessable
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.
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.
Definitally, please put them in
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).
Toolkit Dependancies: org.xith3d.primitives
3rd Party Dependancies: Gymli
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.
and The 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)
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…
[quote="<MagicSpark.org [ BlueSky ]>,post:5,topic:25980"]
I think we will end up with a 10 Mo Xith toolkit that everyone needs and yet nobody needs everything that’s into it.
[/quote]
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.
to coordinate and provide resources for Xith3D tool development
to create a central repository for Xith3D tools so they are easily accessable
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.
Okay.
[/quote]
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 8)
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!!
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…
Is the build.xml ant buildfile supposed to build anywhere ? I’ve got error when compiling (it says it doesn’t find xith-tk/third-party but it exists in my Eclipse project), and I need a fresh jar file…
I never had compile problems, probably because I haven’t used the ant-build files, but have set the locations of my libraries directly in the project settings (eclipse)
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 )
)