next »

[Mathias 'cylab' Henze]

Hmm, I am for a BSD licence, since anything else is poison for commercial acceptance (at least that's the situation in my work environment, which is J2EE). I also strongly disbelieve the myth, that a more restricted licence would attract more contributors - I think it depends more on the propagation of the library and the quality of the development community.

[Marvin Fröhlich]

Hmm, I am for a BSD licence, since anything else is poison for commercial acceptance (at least that's the situation in my work environment, which is J2EE). I also strongly disbelieve the myth, that a more restricted licence would attract more contributors - I think it depends more on the propagation of the library and the quality of the development community.

Good points. But as far as I know the main difference between GPL and LGPL is exactly, that LGPL is free for commercial use. You just cannot use the source without making your own source free, but you can use the lib. So there's nothing, that would keep you from using it in a commercial project.

Marvin

[Mathias 'cylab' Henze]

Yeah, I know. It's more of a prejudice in my environment: if there is a GPL in the name, there is a catch. Executives think like "if one of our working students just copy such code into ours without knowing about legal problems, we are doomed... so just don't touch anything like that at all"

Other than that I personally prefer code with BSD licence, because I CAN copy code into my sourcecode if I want to. Even if I never would need or do this, I would still discard a similar library with a more restrictive licence - maybe there are others out there like me.

[Marvin Fröhlich]

OK. Very good points. Other points from anyone?

['n ddrylliog]

I fully agree with Mathias. +1 for BSD

[Marvin Fröhlich]

Wow. That was fast . the project is approved: http://sourceforge.net/projects/jagatoo/

I've switched the license to BSD.

Amos, I've added you to the devs list. Anyone else, who wants to contribute?

Marvin

[Mathias 'cylab' Henze]

Cool!

Some thinks I like to point out:

- I think the CamelCase JAGaToo looks a bit hackish... I would find all lower case "jagatoo" more elegant
- I still think "abstraction" should not be part of the name... "Java Gaming Tools" is more striking

these are of course personal opinions, so treat them like you want

Regarding the OpenGL-Wrapper, I found this post on javagaming.org.

Would this not solve the LWJGL/JOGL code duplicity problem right away?

[Marvin Fröhlich]

- I think the CamelCase JAGaToo looks a bit hackish... I would find all lower case "jagatoo" more elegant
- I still think "abstraction" should not be part of the name... "Java Gaming Tools" is more striking

these are of course personal opinions, so treat them like you want

I like the camel case word more. And I want abstract to be part of the name .

Regarding the OpenGL-Wrapper, I found this post on javagaming.org.

Would this not solve the LWJGL/JOGL code duplicity problem right away?

Well, this would force us to have both LWJGL and JOGL jars in the classpath even if only one of them is to be used. And we would risk incompatiblities and problems in one lib to tear down the other.

Additionally I have some caching plans within the abstraction layer.

Anyway, thanks for the hint.

Marvin

[Mathias 'cylab' Henze]

I like the camel case word more. And I want abstract to be part of the name .

And we would risk incompatiblities and problems in one lib to tear down the other.

Additionally I have some caching plans within the abstraction layer.

I don't think there will be problems like that, but who knows...

I just think an OpenGL wrapper would be a HUGE amount of work not reducing code redundancy, but increasing it. Especially if you want this to be useful for others you have to implement a lot of methods, abstract away window creation and peer handling, maybe implement different native buffer handling for the two GL libraries etc. etc.

I fear we will not see you here again, once you started this

[Marvin Fröhlich]

I just think an OpenGL wrapper would be a HUGE amount of work not reducing code redundancy, but increasing it. Especially if you want this to be useful for others you have to implement a lot of methods, abstract away window creation and peer handling, maybe implement different native buffer handling for the two GL libraries etc. etc.

I fear we will not see you here again, once you started this

Well, I would not want to implement everything. I would implement the part, that we need for xith and that's not too much. Of course, implmenting everything would be a lot of work. If anyone wants to use it for his lib and there are some methods missing, he would have to implement them. That's one of the resons, why I see this lib to be highlly dependent on contributions.

And I don't think, there should be an abstraction for context creation (for the first verion), 'cause this is too different for t least JOGL and LWJGL. Well, maybe it could be a task for a second or thirt version.

So you see, the work is not too much. I would at least want to start with it and see, if it runs out of sight .

Marvin