Nifty-Editor plug-in

[relucri]

Thanks atomix! ,
I actually want to implement it since I saw in your editor . So yeah I have planned to add it but first i need to do some refactoring in attributes generation . In this way also the propriety tab will be more powerful and easy to use , more over the plug-in will benefit . About

@atomix said: More over, he want to align bunch of buttons "Horizonal" at a time.

Do you mean , select three buttons ( in absolute layout ) and then aling horizontal or a bunch of panel and set childLayout of them to Horizontal ?

In both I need to add multiple selection that is also a planned feature but I will add a bit later .

Thanks again , I love to discuss about this things ^^

Bye Cris : )

[relucri]

Hello! , as usual I want to talk with you about what I’m going to implement in these days . It’s a better attributes generation for GElements . Right now the attributes are generated by an utility class which reads them from nifty-gui xsd . If you read the xds you may notice that no information is reported about control specific attributes ( as it should be ). So I worked around this by manually add some fake types to the schema and then read them using the previous utility class.
For instance :

[xml] <xs:complexType name=“windowType”>
<xs:complexContent>
<xs:extension base=“elementType”>
<xs:attribute type=“xs:string” name=“closeable” use=“optional” />
<xs:attribute type=“xs:string” name=“hideOnClose” use=“optional” />
<xs:attribute type=“xs:string” name=“title” use=“optional” />
</xs:extension>
</xs:complexContent>
</xs:complexType> [/xml]

This of course has no use in xml validation . Also all the attributes are mixed ( elements specific with controls specific and also style specific ) this is bad and not easy to use for the final user . Well I going to divide all attributes in three categories Element , Style and Control . About Element and Style category there’s no challenge here I could use my previous class and retrieve all the information from the xsd. Controls, actually Control parameters ,are harder . Here is my thoughts :

1. The nifty-gui manual says that control parameters are specified in the controldefinition by using a special syntax that is attribute="$parameter". So I could search these parameters runtime . This is a good strategy also for the custom controlDefinition , but it has a problem : not all controls have their parameters specified in that way . For example checkBox doesn’t have any defintion of its parameter “checked” , because it can’t be assigned to any attribute , I guess.

2. Use inheritance and delegate parameters to all the classes that are subclass of GControl . This is easy and it doesn’t require any changes in nifty-gui ,but it would hardcoded the attributes in the classes . Furthermore user defenition of custom controls becomes complex .

3)Use annotation. Create a NiftyControlParameters annotation that could be added both to GControls subclasses and Control class . This also won’t effect nifty-gui and It’s good for custom control defintion but the parameters are hard coded again.

4. Use a sort of convention , like in Xaml or java bean, and invert definition of parameters from xml->java to java->xml . This means that all the parameters are all properties of Controller class which satisfy this convention :
   [java]
   public String getX();
   public void setX(String value);
   [/java]

these methods could be hidden from the outside and added to the the controlDefenition impl instead of the interface ( not in Button.java but in ButtonControl.java ) .

5. We could keep the current implementation and only add an attribute in controldefintion tag. This attribute is a list of all the possible parameters for that control .

Since this could touch nifty-gui , what do you think @void256 ? Which is the best implementation we could do ? . Anyway all other suggestions are welcome.

Bye , Cris

p.s. Notice that these changes are important also for the plug-in since the attributes will be copied in to Nodes properties.

[relucri]

Meanwhile I’ll also working on 0.5.9 final verision! have a look here to track the progress github issues . Here also a cool screenshot about new relative path support :

What do you think about mine approach ? Is similar to library chooser of Netbeans .