Nifty Editor Final Devblog

Hello guys,
We come to the end! , as I said in the previous thread these days I focused on import and manipulation of styles of control, instead of add effects support. The result is quite satisfying since now nifty-editor is in a state that could be used in the regular day-work. Not for complex gui maybe, but it does its job! Fast prototyping could be an other use case that the editor could easily deal with. Well but what is import of style&control ? and how they works?
Import style e control means that you can create a new style using the default JME wizard and link it in the visual editor. The same thing is for controls, create your control or more than one and link in the editor. The editor will keep a reference to the file and if you change it , if you want to be uploaded again in the visual editor just do left-click on style node and Refresh. I know that a user would see this thing automatically but for some reasons the exact same function won’t work if I use a FileChangeListener. Of course if you has more than one element with a linked style when you click refresh they all be updated. This feature doesn’t apply to controls tough , mostly because nifty doesn’t permit a runtime modification of controls. It could be implemented in the feature using eventsbus + nifty-editor api but it’s a workaround. I’ve also added some templates to easly create an empty style and control. There’s a special folder used for all controls style , I thought that it’s quit handy to have a template to apply a style to a control ( i.e. button)

To show you better what nifty-editor can do here is a boring video(Sorry i coudn’t make a other more sophisticated),it’s just me trying to make a login screen:
[video]https://www.youtube.com/watch?v=4iTVPYMEtH0[/video]

About the future , Finally I’m going to graduate so this month will be pretty full of things to do. Due to this nifty-editor development will be paused for a while, but I’m still here for support both nifty-gui and the editor! you all have a free pass to @mention me!

After that these are to most urgent task that I want to complete :

  • Add all control style template( simply copy from the default-styles)
  • Better toolbar
  • Editor for most of the properties ( including fonts and image-mode , it’s almost done but i needs clean up)
  • Popup support
  • Effects support
  • Other things that I don’t remember now :smiley:

I hope you enjoy the new version since It has also new icons :slight_smile: .

download

10 Likes

Really nice!
I will definitely use this.

Thanks! I’m really glad that you are going to use it! :slight_smile:

Also just a note for my future self, making an editor for both controls file and styles should be really simple. Just add the model in GuiEditorModel with all necessary events and wire up the gui with them. For both I could simply use again the same NiftyGui preview since it only render nifty but it has a dependency the GUI class.
The control editor would be something where you can drop elements and edit them like GUI and the style editor wouldn’t need to use the same palette of gui ( maybe a palette with attributes and effects ) and could have a gui where you choose an elment and see the style applied to it.

What do you thing about these ideas ?

1 Like

First of all great work with the editor! I think adding support for custom controller classes could first just be done with the code files, i.e. just being able to use your coded controllers in the editor. The editor could even look for existing controller classes in the projects classpath. Idk exactly what you mean by “style editor” but being able to at least select styles present in the classpath would already be great.

+1 for support for custom controls.
My UI uses custom controls and the editor was not able to open it.
Thus I havent been able to see it in action (yet).

First of all great work with the editor! I think adding support for custom controller classes could first just be done with the code files, i.e. just being able to use your coded controllers in the editor. The editor could even look for existing controller classes in the projects classpath. Idk exactly what you mean by “style editor” but being able to at least select styles present in the classpath would already be great.

Not sure if I was explained my self bad or I didn’t undestand your comment :slight_smile: . First I wanna to say thanks for your kind words and all the support of you and the other core devs. About this topic instead I was speaking about nifty custom controls , the xmls defenitions of them not the class that take care of them in the java side. I want to add something that could help to build them visually like the gui editor. Also about style editor I was referencing about a visual editor to make changes in nifty style-defenition files. Maybe something like a css editor.

+1 for support for custom controls. My UI uses custom controls and the editor was not able to open it. Thus I havent been able to see it in action (yet).

This last version already supports controls! :smiley: . So if you have them in your assets folder the editor should display the gui :). If it’s not please tell me , it could be a bug! . For a reference to how add controls and create them see the video from 2:56 and after. :slight_smile:

Okay I am in the process of embedding the editor into our current SDK and the niftyeditor jar files are not wrapped into the plugin yet. Can you tell me which ones I best use for the editor? jada.ngeditor.controller.CommandProcessor seems to be missing in the jar that is in the release/ext folder…?

Update: I built the version from github, now I just need to know which of the dependencies in “lib” are actually needed by the editor, some of the nifty dependencies are not really used, are they?

Okay I found an issue with the editor. Because it tries to load the nifty-default-styles.xml (and probably other xml files too) from the normal classpath and not from the project classpath it fails to load it when the nifty jars are not wrapped in the plugin. Even though the nifty classes are available though the “SDK Libraries” import, other resource files cannot be loaded. Generally in the NB Module system (as well as in OSGI) resources cannot be loaded from another plugins classpath, only java classes. The classpath of the project however should have these resources available, you could access it via the ProjectAssetManager.

I think you can also just register the resource loader for nifty as it was done before, see here: https://github.com/jMonkeyEngine/jmonkeyengine/blob/3.0/sdk/jme3-gui/src/com/jme3/gde/gui/multiview/NiftyJmeDisplay.java

Problem is that your editor creates the nifty instance and the SDK wrapper cannot pass the resource locator…

Changed the J2DNiftyView this way to be able to add a resource locator:
[java]diff --git a/src/jada/ngeditor/guiviews/J2DNiftyView.java b/src/jada/ngeditor/guiviews/J2DNiftyView.java
index 042d954…b59095e 100644
— a/src/jada/ngeditor/guiviews/J2DNiftyView.java
+++ b/src/jada/ngeditor/guiviews/J2DNiftyView.java
@@ -20,6 +20,7 @@
import de.lessvoid.nifty.java2d.renderer.GraphicsWrapper;
import de.lessvoid.nifty.java2d.renderer.RenderDeviceJava2dImpl;
import de.lessvoid.nifty.tools.TimeProvider;
+import de.lessvoid.nifty.tools.resourceloader.ResourceLocation;
import jada.ngeditor.listeners.GuiSelectionListener;
import jada.ngeditor.listeners.events.RemoveElementEvent;
import jada.ngeditor.listeners.events.SelectionChanged;
@@ -131,13 +132,19 @@
}

 public void init() {
  •    init(null);
    
  • }
  • public void init(ResourceLocation resourceLocation) {
    InputSystemAwtImpl inputSystem = new InputSystemAwtImpl();
    FontProviderJava2dImpl fontProvider = new FontProviderJava2dImpl();
    registerFonts(fontProvider);
    RenderDeviceJava2dImpl renderDevice = new RenderDeviceJava2dImpl(graphWrap);
    renderDevice.setFontProvider(fontProvider);
    nifty = new Nifty(renderDevice, new SoudDevicenull(), inputSystem,new TimeProvider());
  •    if(resourceLocation != null){
    
  •        nifty.getResourceLoader().addResourceLocation(resourceLocation);
    
  •    }
       java.net.URL empty = getClass().getResource("/jada/ngeditor/resources/empty.xml");
       try {
           nifty.fromXml(empty.getFile(),empty.openStream(), "screen1");
    

[/java]

Still doesn’t work completely, it seems the editor libs need some special nifty 1.4 snapshot methods… :confused:

[java]
java.lang.NoSuchMethodError: de.lessvoid.nifty.Nifty.scheduleEndOfFrameElementAction(Lde/lessvoid/nifty/elements/Action;Lde/lessvoid/nifty/EndNotify;)V
at jada.ngeditor.controller.GUIEditor.createNewGui(GUIEditor.java:218)
at com.jme3.gde.gui.view.NiftyGuiVisualElement.loadGui(NiftyGuiVisualElement.java:345)
at com.jme3.gde.gui.view.NiftyGuiVisualElement.componentOpened(NiftyGuiVisualElement.java:231)[/java]

Hey normen! sorry that you are having so much problems!
yeah I used the latest nifty build! I think that the repo miss the updates about ext/lib folder. The whole plug-in depends only to latest nifty-editor build that you can download form my site . Tell me if it works! :wink:

Sorry again

@relucri said: Hey normen! sorry that you are having so much problems! yeah I used the latest nifty build! I think that the repo miss the updates about ext/lib folder. The whole plug-in depends only to latest nifty-editor build that you can download form my site . Tell me if it works! ;)

Sorry again

Thanks, I fixed the problems half way by doing what I described above, still I am getting the mentioned issues with missing methods using Nifty 1.3.3. Plus it would require the change I posted to the NiftyEditor library, tell me if its okay like that or if you want to do it another way (e.g. by passing the locator before calling init()) I’m in contact with void to update Nifty to 1.4.0, I hope you don’t use anything thats only available in an unreleased snapshot version.

Unfortunately yes :cry: . I’ve just remember that I made a little change to nifty main repo to support style reloading… So it wouldn’t compile. Maybe I don’t have a clear vision of the problem but Can’t we use the nifty version embedded in my build ? I mean why the plug-in should be forced to use the nifty-gui distributed with sdk ? Also about your changes yeah I saw what you made but nifty-editor uses an internal mechanism to handle assets, nothing fancy but it simply set the assets folder taked from ProjectAssetManager. Usually there’s no need to implement such ResourceLoader, but I’m here to see your points.

@relucri said: Unfortunately yes :cry: . I've just remember that I made a little change to nifty main repo to support style reloading... So it wouldn't compile. Maybe I don't have a clear vision of the problem but Can't we use the nifty version embedded in my build ? I mean why the plug-in should be forced to use the nifty-gui distributed with sdk ? Also about your changes yeah I saw what you made but nifty-editor uses an internal mechanism to handle assets, nothing fancy but it simply set the assets folder taked from ProjectAssetManager. Usually there's no need to implement such ResourceLoader, but I'm here to see your points.

The point would be that the user can edit nifty files with the nifty version and nifty style files he has in his project, not with default ones that are bundled with the editor. This way no matter what default-controls and style the user has loaded in his project, they will be used to edit the files. Ideally this would even be true for the nifty version but then you’d have to rewrite the whole class loading bit to load from the user project.

Anyway its easier to update the nifty libraries once in one place for the whole SDK, I could just as well ask the question “why force the user to use the nifty version that comes with the editor plugin?” As it is now, the “SDK Libraries” plugin already contains the nifty libraries anyway and its already a dependency of the editor.

The point would be that the user can edit nifty files with the nifty version and nifty style files he has in his project, not with default ones that are bundled with the editor. This way no matter what default-controls and style the user has loaded in his project, they will be used to edit the files. Ideally this would even be true for the nifty version but then you’d have to rewrite the whole class loading bit to load from the user project.

Actually I didn’t thought about this use case! I thought that people would only use assets and don’t modify standard controls or styles! So thank you for your changes if you could make a PR I’ll glad to merge it! .
However about nifty-core if we use the SDK version we will loose style reloading and that it’s quite bad. I mean that starndar nifty 1.4 can’t reload styles if the were changed on their definition files. The upstream still doesn’t have this feature because I didn’t make a PR with that. I don’t even know if it will be merged since it’s a bit editor specific use case. If we will leave the version embeded with the edtior I have more freedom and I can update it more often than SDK. For example considering that now nifty-style mechanism will change ( but it still can read the old style files ), the editor could have this new feature as soon as void will merge it. Anyway the point it’s that the user is not forced to use the same nifty version of the editor even if it’s different of the SDK’s one, but he can still take advantage of that by using a more powerful tool. Also as long as the editor will display the gui correctly, there’s no need that it shares the same version used from the user.
I hope I was clear, please ask if I wasn’t .

@relucri said: Actually I didn't thought about this use case! I thought that people would only use assets and don't modify standard controls or styles! So thank you for your changes if you could make a PR I'll glad to merge it! . However about nifty-core if we use the SDK version we will loose style reloading and that it's quite bad. I mean that starndar nifty 1.4 can't reload styles if the were changed on their definition files. The upstream still doesn't have this feature because I didn't make a PR with that. I don't even know if it will be merged since it's a bit editor specific use case. If we will leave the version embeded with the edtior I have more freedom and I can update it more often than SDK. For example considering that now nifty-style mechanism will change ( but it still can read the old style files ), the editor could have this new feature as soon as void will merge it. Anyway the point it's that the user is not forced to use the same nifty version of the editor even if it's different of the SDK's one, but he can still take advantage of that by using a more powerful tool. Also as long as the editor will display the gui correctly, there's no need that it shares the same version used from the user. I hope I was clear, please ask if I wasn't .

Well the same issue occurred when I did add the jar files you had in release/ext, probably because the nifty libraries already exist in the SDK Libraries set as I said. But still I’d rather ask @void256 to add the features and make a 1.4.1 release instead of working with snapshots and including Nifty three times in the SDK. Its okay to have a development version using snapshots but for a release I think its somewhat of a no-go. At any instance I can make a PR for the changes (or you give me commit access to your repo as I checked it out directly and made the changes there).

Ok I’ll make a PR for my changes to nifty-gui but I don’t think that @void256 would make a release just for that… we need to wait until it will be out. About your changes I would prefer a PR if it doesn’t annoying you, so I could test them in my repo.

Hello, I’ve sent the PR you can review here. I know that it’s early but @void256 if you would say something about the 1.4.1 roadmap I can give an hand to reach it ! . I think that it could include at least the refactoring of style system.

1 Like

Any news on this?