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
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 : )
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: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” />
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 :
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.
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.
- 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 :
public String getX();
public void setX(String value);
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 ) .
- 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.
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 .