Just out of general interest since time moves on, which IDE do you primarily prefer (e.g. you use netbeans at work but prefer intellij). I ask too because a basic model viewer and particle builder etc might be worth the effort on IDE’s other than netbeans if they are popular enough. Anyway. Thank you for voting!
Paul and me were discussing a kind of SPI for the editor stuffs so that editor modules could be used in any application that supplies the SPI, including jME applications themselves. We intended to test the SPI by implementing it in the SDK by me and in a lemur-driven in-engine editor by Paul.
This way any IDE or anyTHING really could use “editor plugins” for jME. Think games using terrain editors and stuff.
That sounds like a cool idea. I wonder how hard it would be to handle the threading, any thoughts on that? I assume that for lemur the editor widgets should run in the same thread as the lemur code, in a swing/AWT-setting the editor stuffs and the embedding framework would want to run on separate threads I guess.
We actually started this with Paul. It’s called Spix. It’s still experimental and we don’t have much time to work on it. I work on it from time to time and I have the basis of a scene editor made in swing based on it.
Was using Eclipse back in cpp times… was using Intellij for some time since then… Android Studio few times (this one looked the most sensitive to updates btw)… JME stuff goes bit easier with native IDE… looks like any modern system is no worse than OK now ( if it is NOT MSVS #$%@#, of course ).
Sort of. Control is inverted. Each UI would provide services like a main menu or toolbar that the components could hook into. Mediation is also provided so that components can communicate in a standard way. Even the UI services are composed in a similar way so you can include or not what you need in your applications “configuration”.
The stuff we did is only in prototype form. This is the version I planned to throw away and rewrite once we’d figured everything out. The mediation model still needs work to implement lists and trees before I could do that. I sort of feel like there may still be some fundamental changes to core to support that.
Building the mediation layer to handle the Swing/AWT vs JME threading was always the trickiest part… and that’s mostly solved for non-list properties.
Only just started using jmonkeyengine (same with java actually) so going on an IDE adventure is not on my todo list right now especially as so far JME SDK has worked very well.
Well… my 2 cents:
(Only talking about java development)
I’ve used extensively eclipse during almost 10 years in my previous work. Though I stopped to use it about 2 or 3 years ago.
I extensively used netbeans through the JME sdk during 6 years. Though I stopped using it when we decided to stop supporting it last year or so.
Since then I use intellij because I’ve been able to have a couple of open source license for the core team.
All in all… You’ll achieve whatever you want with ANY of them. It’s really just a matter of taste… there are some great things in each of them and there are some crappy things in each of them.
I was tired of eclipse because of the sporadic background task that was just freezing the whole ui. (for example indexing a maven repo does that). Other than that, solid java support, and tons of plugins.
I stopped to use Netbeans because we stopped the SDK support. I thought that I should learn something else to switch the approach at JME dev. Also I found the gradle support very poor in netbeans. Ho and… well… there was also a sporadic background task that was freezing the UI (I don’t remember exactly what but it was related to the projects configuration). Though I have to say that to me it has the best java support of all IDEs
I started on intellij because I could have a license…else I wouldn’t have. Also there is a bit of Hype about it since a couple of years. I like how the UI is done and it’s quite snappy. Java support was a bit under netbeans’s but with java 8 they did a really great job. So, it’s a nice IDE. But guess what? sporadic background tasks that freeze the UI…I guess it’s a feature because all of them do it…
I have similar experience to nehon. I’ve used intellij on the day-job for a few years. It has the best support for other languages than Java so Scala, Grails et c.
On my spare time I use netbeans (or jME) - I like this the best.
Eclipse was a few years since I used.
All in all, they are basically the same, all have good features and some strange bugs. It takes a while to get used to each of them but I can’t say one is a lot better than the other. I really don’t understand the hype around IntelliJ. It’s nice and all but not worth the money if you only do Java-development IMO.
I have built plugins for eclipse and Netbeans, both have some seriously strange APIs but none is better/easier than the other.
I used vim in the past for nearly anything. But the beginners section of JME brought me to JMEs famous SDK and I really like it, I liked that the examples simply worked back then, I liked the colours of the IDE (I even start to get use to the new colour theme from @Darkchaos). I like that I simply can do a blend to j3o, which almost always worked for me.
I would love to see kind a gradle based JME plugin which also would have a working blend to j3o (I have workarounds for this).
In the past I used eclipse sporadic, but I never liked it much, can’t tell you why, just… a question of taste I guess.
Yep. But I plan to have a more automated way, maybe by a simple helper jar and gradle or so… But for the moment that “have another standard JME project open” is good enough.
@Ali_RS once provided me some links, I have my assets already in a gradle sub project and that sub project could be again a standard JME project just need to set the class path properly, but as a java noob I didn’t manage that class path thing, but maybe i’ll give it a second try, but not at the moment.
The Problem is you cannot easily merge the gradle Project Class with our sdk Project classes since they dont seem to Share the same baseclass. On the other Hand at least the j3o Conversion could be Added (however an Asset Directory has to be present then)
I guess not to bother with it, since, as said above, we have quick-and-easy workaround. And implementing the conversion itself wouldn’t actually make this process much simpler, since anyway, you will still have to open gradle sub-project to appear as project, and even after that won’t be able to invoke SceneComposer to look at the model.