First of All,
We try our best to keep the SDK up and you can continue to use the SDK for features such as android, deployment and such.
Heck, you could even use it for regular Java Projects I guess.
The only thing which happens when not updating the SDK is (for example):
When PBR is out in 3.X, the SDK’s Material Editor won’t have those Materialvalues inside
So what it means is only: Future breaking changes in the Engine won’t be held back until someone updated the SDK.
This and maybe some bugs that won’t be fixed (soonish).
Moving the tools into seperate projects makes sence if you want them for the command line (for example automated .blend->.j3o, Changing all Materials, whatever), however in Terms of SDK-Usability, it would really suck.
My personal opion is, that I could learn everything I needed for Wizards, Menu Actions, Property Files, etc. in just a Weekend.
Netbeans is complicated but they have a good documentation plus if you only want to fix things or implement something similar, you can always take the existing code and go from there.
So it’s absolutely doable if you have the time.
So Guys, please don’t panic
Also it’s OpenSource, which means: No matter what happens, someone can come later and fix it
Oh, it never was a complain… I’m from the school of “if you didn’t participate, don’t complain about the state”.
My personal opinion is that you learn quicker than I do and are a lot more comfortable with multi-threading, awt etc.
Also, getting the sdk ready to be modified is hell… I went though it and still have a bitter taste in my mouth.
My reasoning behind moving those tools out of the sdk was to make them single-threaded and separated. This makes it a lot easier, for maybe 9/10th of the user base to create such tools and share them. Cfr my personal experience expressed up there. Also, no getting the sdk ready to modify it problems.
But you sure reassured me, and I am grateful for your work.
Being comfortable with AWT and MultiThreading is a good thing indeed but you might not even need it.
Netbeans has the Mantisse Builder which means a GUI to design GUIs.
Multi-threading is only needed for operations which take long and can be parallelized.
Take the Material Panel for example, it could freeze until the material is loaded because it a) doesn’t take long and b) you couldn’t use it beforehand anway.
I am not really sure on what you mean with “getting it ready to be modified”.
I guess if you have a specific problem you’ll get fast help.
I am also not sure why Single Threading could help you out as you don’t have real Inter-Thread-Communication, which is where the problems are.
Now see here, it’s what you’d find after a few seconds of googling. It shows how to use AWT from a foreign thread.
Then the only thing which has to happen is in the Finish-Button-Method you need to see if thread.isAlive or thread==null (not even started).
You realise this can’t happen right?
Only way to have a single threaded tool would be to have in game GUI for everything. And still… i’d have it multithreaded even in that case. Multithreading is not here to get in the way, it’s here to get your app snappier.
Also in the case of the SDK the only multithreading management you have to do is to enqueue your scene graph modification calls to the JME app.
About netbeans API. I have a fair experience with it, and I can tell you this : Netbeans API is like a highway bordered with barb wire and mine fields, as long as you get on the road it’s ok, if you want to get off track, it hurts really bad.
So basically, you can make wizards in 3 clicks, add properties to the property view, create navigators views, custom editors, new menus etc… As long as you stay in the realm of IDE source based UI, with properties views etc… it’s really great.
But as soon as you want something a bit different from the stock wizard/gui provided… it gets crazy difficult. And trust me when you do a graphical editor, a scene editor and the likes the SDK has, you’re waaaay out of the highway.
I’m new here but I recently found JMonkeyEngine and it does what I was hoping to do from scratch. Which is a solid game engine that integrates tightly with blender. You guys can even import models directly from blender.
Seeing this issue about the sdk made me wonder though. Why spend time developing your own SDK like this when JME is so tightly integrated with blender. Why couldn’t you leverage blender to use it as the visual editor and then have JME convert that scene to the binary format with some hooks to be able to get models by name, spawn models etc?
Those might be things that area already there and I just haven’t run across them yet but it was just a though. One thing that’s a bit hard for me about the netbeans SDK is that it also does support hDPI screens. In blender at least you can scale up the font resolution to get something workable.
Maybe make the scene editor more a part of blender instead of making blender a part of the scene editor? Just a though but I would love to hear what everyone thinks.
Please no eclipse? Even android the biggest supporter of eclipse left it, what about moving to gradle and android studio or jetbrains ide. They offer free IDE’s to open source projects like these, it supports dHPI screens out the box, it’s a lot more flexible and probably more future proof, in my opinion.
It will be possible, but it won’t be done and supported by the core team.If it exists it will be community driven.
We are planning on a system that will allow several GUI to plug over the main functionalities of the Tools.
Though we won’t choose a new IDE and start over the flame war over IDEs. We want to be IDE agnostic.
oh yes, IDE wars and those things, leaving that up to the users makes sense. It would be really awesome if you guys implement the this so that the users can hook whatever IDE or tools into those plugs.
But till then let’s try to support the current sdk, not reinvent the wheel.
When this was first announced I also thought of making an IntelliJ plugin but when I actually started coding I figured out it would be much more useful to help @darkchaos maintain the current sdk.
Are you planning on making/finding an API to allow a single plugin to run in multiple IDEs? If so, I think this would be great but obviously difficult. If not, is it an external program that can interface with Gradle (or something similar) in order to allow for complete compatibility with different IDEs?
I think, developers have to use Eclipse/IntellijIDEA for developing and other tool for working with graphics. So I started implementation my version of editor for jME3. http://hub.jmonkeyengine.org/t/jme3-spaceshift-editor/
Dang, I’m about to come back and the first thing I see is the SDK is struggling. :chimpanzee_confused: Overall, jME3 is of course IDE agnostic, and people can create support for any IDE they want, the more the merrier. I still have the previous SDK installed, I liked the project creating and packing in the current SDK, but I never really used the visual scene editor features.
Anything I can help with? I’ll check out the source code after work, but I don’t really know what all needs to be done, I assume update it to the NetBeans 8.1 Platform…?
