Why not having an ingame/inengine editor instead of the sdk?

User Code & Projects
1
@normen said: To add to the fragmentation of jME libraries? Why do you think people will find it easier to add to a maven repo than creating a plugin library with a wizard? And if they do, why should SDK users be left in the rain?

I really don’t want to start an IDE flamewar here, but its a fact that there are at least 3 big players and lots of smaller alternative program environments out there. Now, i would say that most of the programmers already working with java don’t want to install a separate IDE. Even users who already use netbeans probably don’t want to resetup theire whole programming environment.

This leads to 2 issues, firstly i think there are not sooo many people out there that use the sdk how it is ment to be used, missing/broken functionallity or for whatever reason.
As a follow up all that people have no interest at all writing fixes, or plugins for a editor system they actually cant/dont use in their production…

Don’t get me wrong, i kind of like the idea to have a central toolbox/editor environment. (As you call it, the jmeExperience)

But from my point of view the ultimate goal should be to write the whole thing against jme and not against netbeans, so that every programmer out there could make use of it. Even the hardliner writing a project in vim could start a editor within jme. It could actually be only a jme plugin at all.

[java]statemanager.attach(new Jme3Editor()[/java]
could be all needed to integrate it in your own project.

Once it would work, we could even start the editor while playing our game. While running around you see that the terrain textures are not matching, a simple click on “CTRL+T” opens the ingame terrain editor, and you correct the issue.

If you like it to be integrated into your ide, all needed would be writing a minimal plugin opening a tab showing jme. What i am proposing is to bring the whole idea of the sdk to any production environment out there…

*The pluginsystem could then actually fully depend on gradle, if you want a clickable gui as you have currently in the sdk, no problem i would say. After all the new plugin-plugin would only have to add/remove a single line in the grade file.

**Consider this as an option for 3.2 i would say.

2
@zzuegg said: I really don't want to start an IDE flamewar here, but its a fact that there are at least 3 big players and lots of smaller alternative program environments out there. Now, i would say that most of the programmers already working with java don't want to install a separate IDE. Even users who already use netbeans probably don't want to resetup theire whole programming environment.

This leads to 2 issues, firstly i think there are not sooo many people out there that use the sdk how it is ment to be used, missing/broken functionallity or for whatever reason.
As a follow up all that people have no interest at all writing fixes, or plugins for a editor system they actually cant/dont use in their production…

Don’t get me wrong, i kind of like the idea to have a central toolbox/editor environment. (As you call it, the jmeExperience)

But from my point of view the ultimate goal should be to write the whole thing against jme and not against netbeans, so that every programmer out there could make use of it. Even the hardliner writing a project in vim could start a editor within jme. It could actually be only a jme plugin at all.

[java]statemanager.attach(new Jme3Editor()[/java]
could be all needed to integrate it in your own project.

Once it would work, we could even start the editor while playing our game. While running around you see that the terrain textures are not matching, a simple click on “CTRL+T” opens the ingame terrain editor, and you correct the issue.

If you like it to be integrated into your ide, all needed would be writing a minimal plugin opening a tab showing jme. What i am proposing is to bring the whole idea of the sdk to any production environment out there…

*The pluginsystem could then actually fully depend on gradle, if you want a clickable gui as you have currently in the sdk, no problem i would say. After all the new plugin-plugin would only have to add/remove a single line in the grade file.

**Consider this as an option for 3.2 i would say.

I will probably add an option to add maven artifacts to SDK ANT projects more easily via the project properties panel. Other than that I don’t agree. What eclipse does doesn’t mean that its the standard for java development. In fact NetBeans is the reference implementation for a Java IDE, always has been.

But all apart from that we repeatedly stated that we don’t see jME as a java library but as a gaming SDK. That means that even if you have extension libraries that strictly are only for the engine part, ideally you have editors for the SDK to use these libraries as well and those cannot be only maven artifacts, let alone editors for every Java IDE out there. So the point of “bringing the whole SDK experience to all IDEs” is utterly flawed. Does google provide Android GUI editors for NetBeans and IntelliJ? No, they don’t, so I use Eclipse when I want to use that. Thats not necessary for jME android apps and even hinders you to deploy them on iOS, so thats no argument for making jME/Android completely dependent on eclipse either. But as I also stated, with the new plugin repo we can make strictly jar-only libraries available though maven as well, as soon as we have a proper maven deployment for 3.1 in place.

Nobody complains that they have to use Unity to write javascript or C# code… And again and again, nothing stops you from using any IDE (or vim) with the ANT project the SDK creates. I don’t get why eclipse users (and yes, its solely eclipse users complaining in this manner, the IntelliJ people just get along with how things are) are so narrow minded about using their IDE and the way it does things. It uses buildr for gods sake, who in the world uses buildr?

Edit: And in fact I have three versions of NetBeans plus the SDK and Eclipse installed and I love the fact that I don’t clutter one IDE with stuff I don’t use for e.g. web development, C++ development, PHP development, java card development or jME development sessions. I don’t think am alone there. Plus you’re mistaken about the amount of users using the SDK, again, its your bias.

3
@normen said: So the point of "bringing the whole SDK experience to all IDEs" is utterly flawed. Does google provide Android GUI editors for NetBeans and IntelliJ?

At least for Intellij there is a gui editor. Actually android studio is probably going to be the next android dev reference platform.

My point of bringing the sdk experience to all IDE’s was to program the whole editor with jme. inside jme. as app state. Easily portably to all IDE’s, easily to include in your own game.

4

OT: Unity is a wrong example, because editing C#, J# is not done in Unity itseft, but in a third tool. And Unity is by default provided MonoDevelop, but lot of dev reconfigure Unity to use Visual Studio or an other tool (In my previous job, I used Xamarin with Unity). JME SDK whish to provide a more Integrated environment.

5
@normen said: Edit: And in fact I have three versions of NetBeans plus the SDK and Eclipse installed and I love the fact that I don't clutter one IDE with stuff I don't use for e.g. web development, C++ development, PHP development, java card development or jME development sessions. I don't think am alone there.

Thats because some ides tend to get slow/unstable when using lots of plugins :wink:

And not sure about the sdk. Having it installed yes, but how many are using stuff like the sceneeditor to actually build a whole level? At least from the people in irc only one used all features, all others mainly for j3o converions… Only a small fraction of users and not representative, i know, but its my personal feeling that some good features are not used at all.

//But enough OT from my side. Loving maven :slight_smile:

6

Well the amount of half-done “editors” for jME speaks a different language, if all of these energies would have been invested on the SDK instead we would have something that would top UDKs editor by far. But anyway, my incentive to continue developing the SDK is at an all time low anyway (also thanks to your thoughtful nagging and no help). So I guess I can come back in a year and see your awesome IDE-independent editors?

Edit: By the way I intended to change the way you create editors for the SDK to a more AppState-based “in-engine” approach for 3.1 but I guess I would only get opinions on how it should be done differently instead of actual plugins. So I guess not.

7

You can.

–edit–
Sorry I’m an idiot… when I clicked the title, no posts were there, not even the OP one, hence my stoupid reply :D. Nevermind me :).

8
Well the amount of half-done “editors” for jME speaks a different language, if all of these energies would have been invested on the SDK instead we would have something that would top UDKs editor by far
Totally agree with that... what I still don't get it's why opensource projects are full of duplicates-versions that are dead because they were a one-man project... . I know that start your OWN project seems cool but you loose the power of develop in community and also make the first project weaker . In my opinion the guis for JME is a good example, even if they are quite different ( and I understand the reasons why the were developed ) if all that effor was focused on nifty-gui, maybe now we have a kick-ass 2d gui framework...

Just my two cents.

9
@relucri said: if all that effor was focused on nifty-gui, maybe now we have a kick-ass 2d gui framework...

To clarify, there are only two JME GUIs: Lemur and TonegodGUI… and there is nifty-gui which is an adapter to an engine-agnostic 2D GUI. These are two separate categories to me. I could never ever in a million years have done what I’ve done with Lemur in nifty… nor would nifty accept any such changes (and rightly so).

10

So good choosen thread title normen. I actually tough you where out of puberty. So if you try to offend me get at least your facts straight:

  1. If you ever found me referencing or requesting eclipse support only quote me
  2. If you would have read my text instead of reading over it and just read: “sdk is bad… bla bla bla… eclipse bla bla bla… this guy want piss on me bla bla bla” you will see that i proposed an in-engine appstate like method.
  3. How can you not see that having the same functionallity as an in-engine editor would be better then the current state?
11

the javafx port also is not an other project to implement a gui system in jme?
Thanks for clarification I have a high over view of the other two library since I don’t use them so much. As I said I understand the reasons that leads you and tonegod to make your own gui framework “JME native” and surely they make jme more flexible at gui level. But at the high level are they all gui framework right ? Or maybe I can’t see the real difference beetween them. I wont to be polemic, sorry if I sound so… .

12
@zzuegg said: So good choosen thread title normen. I actually tough you where out of puberty. So if you try to offend me get at least your facts straight:

  1. If you ever found me referencing or requesting eclipse support only quote me

  2. If you would have read my text instead of reading over it and just read: “sdk is bad… bla bla bla… eclipse bla bla bla… this guy want piss on me bla bla bla” you will see that i proposed an in-engine appstate like method.

  3. How can you not see that having the same functionallity as an in-engine editor would be better then the current state?

  • Whatever, what IDE do you use then? That you would want to use the maven repo with? (Its a rhetoric question, don’t bother answering, I already said I never heard any IntelliJ users complain about this factoid)

  • If you read my text you would see that I actually addressed that, why would I mention AppState in-engine editors otherwise?

  • Because there is at least one example of an “in-game editor”. It was a one man project and nobody contributed. Proving my point yet again.

    • It doesn’t matter if its NetBeans or another platform, the SDK IS an IDE agnostic editor and I think I said it already, you don’t need to use it for coding. If we made a framework for an “in engine editor” you would have to develop against that, wheres the difference?

    Anyway, I’m off doing other things, Eclipse users have their maven repo now so I hope we can rest this whole discussion.

    13
    @relucri said: the javafx port also is not an other project to implement a gui system in jme? Thanks for clarification I have a high over view of the other two library since I don't use them so much. As I said I understand the reasons that leads you and tonegod to make your own gui framework "JME native" and surely they make jme more flexible at gui level. But at the high level are they all gui framework right ? Or maybe I can't see the real difference beetween them. I wont to be polemic, sorry if I sound so.. .

    Javafx is a bit like nifty in that it renders to a canvas… though at least nifty is rendering it through the JME renderer. JavaFX renders to a texture I guess.

    If you meant the difference between something like Lemur and something like Nifty, well, I can use any JME object in my GUI, my GUIs can be 3D, etc… And by “3D” I don’t mean a plane floating in space. I mean that I could have actual objects in my game be buttons, a dragged stone on the floor be a slider, and so on.

    If you meant the differences between Lemur and tonegodgui, those are more subtle and I won’t really go into them here as they are as much personality driven as anything else. Fundamentally, Lemur was written as a library for making GUI libraries… and it just happens to include a reference implementation (that tries to be swing-like in familiarity). tonegodGUI is more feature rich in a slightly more monolithic API. In fact, it could have used some Lemur code underneath (what Lemur was designed for) for things like picking, input handling, etc. but the timing and climate was wrong for it… and there was some early momentum that prevented it. I think she looked into it at one point not long ago but it may have been hard to retrofit by now or she decided for reasons of her own that it wasn’t worth it.

    14
    Javafx is a bit like nifty in that it renders to a canvas… though at least nifty is rendering it through the JME renderer. JavaFX renders to a texture I guess.

    If you meant the difference between something like Lemur and something like Nifty, well, I can use any JME object in my GUI, my GUIs can be 3D, etc… And by “3D” I don’t mean a plane floating in space. I mean that I could have actual objects in my game be buttons, a dragged stone on the floor be a slider, and so on.

    If you meant the differences between Lemur and tonegodgui, those are more subtle and I won’t really go into them here as they are as much personality driven as anything else. Fundamentally, Lemur was written as a library for making GUI libraries… and it just happens to include a reference implementation (that tries to be swing-like in familiarity). tonegodGUI is more feature rich in a slightly more monolithic API. In fact, it could have used some Lemur code underneath (what Lemur was designed for) for things like picking, input handling, etc. but the timing and climate was wrong for it… and there was some early momentum that prevented it. I think she looked into it at one point not long ago but it may have been hard to retrofit by now or she decided for reasons of her own that it wasn’t worth it.

    Got it thank you for explanation, I think than , correct me if I wrong, the best example of my previous comment would be Lemur and tonegod as you said the latter could be build on top of lemur and I see a bit of redundancy. Anyway it’s not so much trouble because they give a bit of choice in JME.

    A bit OT but I found this video : [video]https://www.youtube.com/watch?v=jEXPw0vKtNQ[/video] . I found all that kind of video quite hilarious XD :smiley: maybe could be placed in the wiki.

    1 Like
    15
    @relucri said: Got it thank you for explanation, I think than , correct me if I wrong, the best example of my previous comment would be Lemur and tonegod as you said the latter could be build on top of lemur and I see a bit of redundancy. Anyway it's not so much trouble because they give a bit of choice in JME.

    For example, here is a simple Lemur example of turning regular JME boxes into interactive GUI components with just a little code:
    http://hub.jmonkeyengine.org/forum/topic/lemur-gems-3-scene-picking/

    And here is a more advanced example showing mesh deformation but essentially the same thing.
    http://hub.jmonkeyengine.org/forum/topic/lemur-gems-4-simple-mesh-deformation/

    The source code is there in both cases if you want to see how little of “Lemur” is required to make them work… because in the end they are just JME Spatials with a control.