Dear Monkeys,
since the core developer team isn’t exactly huge and many features of the SDK could be improved on I am calling out for adopters of some plugins. Work on them hasn’t stopped but an additional developer improving the plugin would help a great deal as the core developers are concentrating on some base SDK features at the moment. Some plugins are mature and self-contained enough so that other developers should easily be able to improve them without having to deal with other parts of the SDK too much.
Of course anyone who wants to adopt a plugin gets personal instructions and help as well. For an overview on what plugins are “open for adoption” and what needs to be done / how complex the plugin improvements might be see the following list:
Font Creator - easy
Basically adding proper support for font styles, improving the kerning and some other minor tweaking and adding of options. Maybe add support for multi-page fonts / other encodings than ASCII, e.g. UTF-8.
Android Support - easy
Test and improve the project integration, bring more options to the GUI level.
Obfuscation Support - easy
Test and improve the ant build script for obfuscating the build. Also obfuscate the libraries.
Texture Editor - easy
Add more features, improve integration.
NiftyGUI Editor - intermediate
Add a palette, wrap the complete nifty XML in “Nodes” (started already) so it can be easily browsed and its properties edited. The NetBeans platform brings a lot of support tools for XML so basically its just tying this together. Drag&Drop support for new items on the UI side would be nice.
Vehicle Creator - intermediate
Bring it out of its alpha state, improve features and range of compatible vehicle models.
Asset Pack Support - advanced
Improve browser and supported functions.
Cinematics Editor - advanced
Make an editor for jme3 cinematics incl. visual timeline with keyframes etc.
Annotation error checks - advanced
Make an annotation checker for jME3 that allows checking for values being set on math primitives that should be “readonly”, e.g. Vector3f.ZERO. This kind of checker can be used in any modern IDE. Work has been laid out in googlecode already.
Editing the plugins should be as easy as installing the “NetBeans Plugin Development” plugin in the jMonkeyEngine SDK or NetBeans, checking out the jMonkeyEngine svn trunk at https://jmonkeyengine.googlecode.com/svn/trunk/ , building the contained freeform project once (!) and then opening the “sdk” project inside the freeform project. As the projects are all started, the initial barrier for getting into the code should be pretty low. See the documentation on developing plugins here.
Any help is very much appreciated!
Cheers,
Normen
I’d be willing to take on the Texture Editor, but my time is pretty limited. So unless that’s a problem I’m volunteering. 
Also, if I remember well, last time I had one heck of a hard time editing the one already there (for my sphere mapped contribution) so a complete walkthrough would be appreciated. Off the top of my head I don’t recall what the exact problems were (I think it was about libraries not included by default in the plugin project, that I had to install myself? Unsure…).
Hm, can’t really tell why that should be. Try following the short but concise description in the post and read further in the linked documentation if something about it is unclear. If that fails then report back
Maybe make sure the SDK version you use is one that was reinstalled lately as the base platform plugins were reset to earlier versions.
I’ll take a look at it later and report back. I’ll probably delete everything and start from scratch.
I know this is mostly to non-core folks, but I’ll be working with Android over the next few days. Hopefully improving documentation for the current state of the art and getting some lessons from it that we can apply going forward. Collaborators are most welcome
Since I’m right now fighting heavily with Nifty and would love to have something like an easy-to-use editor for laying out, I might as well do it myself and have everyone profit from that. I’m going to have a look into it but cannot promise anything at this point.
Dodikles said:
Since I'm right now fighting heavily with Nifty and would love to have something like an easy-to-use editor for laying out, I might as well do it myself and have everyone profit from that. I'm going to have a look into it but cannot promise anything at this point.
Cool! As said, the basics are laid out in the NiftyGUI plugin and its mainly a matter of continuing to wrap the XML in NetBeans nodes so they can be displayed and their properties edited. Then adding a palette / drag&drop support / visual editing.
Yes, I’m already looking at it. So in the package gui.palette you would have the actuals elements like screen.java, panel.java etc. and in the gui.multiview package you have the corresponding node class which basically represent the layout by means of cascaded nodes. Should be manageable… how do I test and debug? By simply commiting, waiting for the hudson build and updating trough JMP? 
EDIT: And where do I specifiy/save the nifty element attributes like “imageMode” etc.? Should I put a HashMap<String,String> inside every class that I create in the gui.palette package?
You can just “run” the SDK project. Theres three project “levels”: The freeform project (purple “triangle” icon) in trunk you only need to build when you make changes in the core engine (jMonkeyEngine3.jar) and want to transfer them to the SDK build. The module suite (yellow icon) is the main SDK project you need to run to start the IDE inside… the development IDE The single plugin projects (blue icon) are where the actual code is.
Edit: Oh and the whole palette stuff isn’t wired up yet.
Edit2: The parameters should be saved inside the Nodes representing the nifty layout / xml.
Understood. We’ll see
After reading through some netbeans platform documentation I wanted to ask things first before starting to implement:
So basically we would have for an UI xml file one NiftyFileNode, which holds NiftyFileChildren which in turn are objects like NiftyScreenNode or NiftyPanelNode that work on DOM elements as API objects.
If this is true, I would need to write something like
[java]
public class NiftyScreenNode extends AbstractNode {
public NiftyScreenNode(String name) {
super(Children.LEAF);
setName(name);
}
@Override
protected Sheet createSheet() {
Sheet sheet = Sheet.createDefault();
Sheet.Set set = Sheet.createPropertiesSet();
Element obj = getLookup().lookup(Element.class);
try {
Property id = new PropertySupport.Reflection(obj, String.class, null);
Property controller = new PropertySupport.Reflection(obj, String.class, null);
id.setName("id");
controller.setName("controller");
set.put(id);
set.put(controller);
set.setName("Nifty values");
} catch (NoSuchMethodException ex) {
ErrorManager.getDefault();
}
sheet.put(set);
return sheet;
}
}
[/java]
I guess I would have such a subclass for every possible element like panel, label, layer etc.
What about getters/setters of the AbstractNodes for the API objects? Do I have to implement them in every Nifty*Node subclass?
Ahh now it gets clearer. The NiftyFileChildren class is a factory that creates for a node with given key element the corresponding children. I guess I understand what I have to do now in general although I have a small setback. Problem is here:
[java]
public NiftyScreenNode(Element key) {
super(Children.create(new NiftyFileChildren(key),false));
setName(“screen”);
this.key = key;
}
[/java]
The error is that I cannot convert ChildrenFactory to NiftyFileChildren. I know it’s a basic Java problem but I can’t find out the right cast.
Yep, exactly. Nodes and children that in the end represent the XML
Edit: Oh, and a factory and actual children are not much different, maybe you can try a base class that uses actual children tho… No need for a Factory I think, just create a class that implements Children. See for example this class:
http://code.google.com/p/jmonkeyengine/source/browse/trunk/sdk/jme3-core/src/com/jme3/gde/core/sceneexplorer/nodes/JmeAssetLinkNode.java
Especially note:
[java]public static class AssetLinkChildren extends JmeSpatialChildren {
public AssetLinkChildren(AssetLinkNode spatial) {
super(spatial);
}
public void refreshChildren(boolean immediate) {
setKeys(createKeys());
refresh();
}
protected List<Object> createKeys() {
try {
return SceneApplication.getApplication().enqueue(new Callable<List<Object>>() {
public List<Object> call() throws Exception {
List<Object> keys = new LinkedList<Object>();
if (spatial instanceof AssetLinkNode) {
keys.addAll(((AssetLinkNode) spatial).getAssetLoaderKeys());
return keys;
}
return keys;
}
}).get();
} catch (InterruptedException ex) {
Exceptions.printStackTrace(ex);
} catch (ExecutionException ex) {
Exceptions.printStackTrace(ex);
}
return null;
}
public void setReadOnly(boolean cookie) {
this.readOnly = cookie;
}
@Override
protected void addNotify() {
super.addNotify();
setKeys(createKeys());
}
@Override
protected Node[] createNodes(Object key) {
if (key instanceof ModelKey) {
ModelKey assetKey = (ModelKey) key;
return new Node[]{new JmeAssetLinkChild(assetKey, (AssetLinkNode) spatial)};
}
return null;
}
}[/java]
Its a very convenient way to get an easy Children object
Yes, I’m just referring to your code. You have a NiftyFileNode class and a NiftyFileChildren class. The latter inherits from Children.Keys and, given an xml element, produces the keys and also the nodes.
You propose (as seen in the JMEAsset example code) to have three classes: A node class, a children class and a child class. I see the children class to be, factually, a factory class that produces nodes. Alright, but what is the child class for?
maybe you can try a base class that uses actual children tho..
Is this what the child class is needed for? Could you explain this point a bit more? Sorry for the noob questions but it is the first time I'm writing beans and I'm only slowly getting all the details...
The children class basically decides what the actual children of that object may be. So for an xml element it would always return all enclosed elements I guess, however it might be useful to leave out some / add other ones for certain properties maybe. The child class in this case is just another AbstractNode in fact that represents one screen element. Each element would be such a “Child”.
I would like adopting a plugin too, but at moment I’m implementing Kinect in jme :). Maybe the Kinect motion capture could interact with the Cinematics Editor in the Future :D.
Well, if you’re working on a kinect mocap plugin then you already do a big favor for the SDK 
Dodikles said:
Since I'm right now fighting heavily with Nifty and would love to have something like an easy-to-use editor for laying out, I might as well do it myself and have everyone profit from that. I'm going to have a look into it but cannot promise anything at this point.
This is a much needed project, thanks a lot man. Also I just realized, @atomix was working on a similar thing not long ago. You ought to take a look at his progress thus far and get in touch to see what he's got in the works.
In terms of the Obfuscation plugin are you wanting a custom built obfuscation library, or are you just wanting reference to an existing library(i.e. proguard) added to the ant script?
I actually started doing research recently on code protection methods for java classes beyond obfuscation. I’ll keep you guys posted with what I come up with. In the meantime, I can look into doing the work on the obfuscation plugin.
feengur said:
In terms of the Obfuscation plugin are you wanting a custom built obfuscation library, or are you just wanting reference to an existing library(i.e. proguard) added to the ant script?
There is an obfuscation plugin using proguard which is fully integrated already, the build script is automatically extended when you enable the function in the project properties. You need to install the "Obfuscation Support" plugin for that (or build&run the sdk from svn yourself as described in the post).
After enabling than on any project, its just about tinkering with nbproject/obfuscate-impl.xml until it obfuscates everything properly without changing the manifest, library names etc. etc. and then posting it back so I can include it in the obfuscation option right away. At the moment it only obfuscates the main jar file I think... as far as I remember thats how far I got until now :)