So what i’m going to do now . First I divided the project in three big steps :
Make the foundations
Take the atomix's work clean the code, make it simpler and merge the last changes in Nifty-Editor ( i.e. it doesn't use a canvas now but a jPanel to render the gui) . Not a big deal but it must be done otherwise the next steps will be compromised. The final result of this first part of development is a really simple editor that is like the current github version of mine . So no style editing , no effects, no code binding but resource handling, element editing , manipulation and maybe a simple synchronization with xml.
Build the walls
This is the most important part . Here i'm going to build a full editor for a nifty gui . First my work will be focused on style editing and deep element editing. What i mean with "deep element editing" is that right now if you have a control in nifty-editor you can edit only the control part and the first element in it for example in a button you can edit the text of the label and the panel . With "deep element editing" you could expand control definition and edit the singles elements that are part of the control . For example in a button you could edit the font of the button, the size of the text , the color etc.. . This is quite powerful because it gives to the final user the complete control to build his gui . Also from deep editing might result a function that iterates of all elements in the current gui and makes a style of it . Then I'm going to work on control editing and adding effects to the elements. This second iteration is quite hard mostly because of deep element editing and style editing but at the end the user will have a real powerful gui editor and he should be able to build all the gui he wants . :-D
Time for the roof
The last part of development it's about coding . Since JME is an IDE it seems fair that nifty-editor should have some level of code interaction . That's why i would add also code binding and even data binding . Code binding it's quite obvious nifty-gui has two ways to handle user interaction controllers and eventbus. For the first nifty-editor should guide the user in adding an interact element and then generate a method in the controller. About the last nifty-editor couldn't do so much but it could provide a simple way to generate the annotation for a particular event and the method ( using netbeans code genartion ) . For data binding is a bit more complex and right now i don't have a clear way to do that . First i think about neatbeans api but it seems it works only with swing, then I found this cool library it realy simple but it doesn't have any license so i don't know if we could use it. The last i could implement a simple framework for this it's quite hard but I could easier embed it in nifty-gui but i should talk with @void.
Well here it is my first draft of development process , any suggestion are welcome! I know this is quite different from what @atomix said but i want be realistic and this is what I can do . Also if you have some tutorial or documentation that i should not do without please tell me here , I want to be more prepared than I can .
Thanks ,I’m trying my best ! I’ve just tried the plugin wizard and actually it is awesome! but now I have a question : Could I add my nifty-editor project as dependency of the plug-in created?
I just updated the plugin wizard allowing you to turn already existing projects into a plugin. Its pretty simple, but the original topic gives instructions.
…
If you already have a project that you created and want to turn it into a plugin, check the “Wrap an existing project” checkbox and locate the built jar file of your existing project. Your project is now a plugin.
Really thanks jayfella! I’ve just tried this new feature and it works as expected . Great work by the way , it saves me some efforts to set up the environment. Sorry I have an other question : Is the jar automatically updated when i edit the project from where the jar is builded ? Or i need to rebuild ?
This is the most important part . Here i’m going to build a full editor for a nifty gui . First my work will be focused on style editing and deep element editing. What i mean with “deep element editing” is that right now if you have a control in nifty-editor you can edit only the control part and the first element in it for example in a button you can edit the text of the label and the panel . With “deep element editing” you could expand control definition and edit the singles elements that are part of the control . For example in a button you could edit the font of the button, the size of the text , the color etc.. . This is quite powerful because it gives to the final user the complete control to build his gui . Also from deep editing might result a function that iterates of all elements in the current gui and makes a style of it . Then I’m going to work on control editing and adding effects to the elements. This second iteration is quite hard mostly because of deep element editing and style editing but at the end the user will have a real powerful gui editor and he should be able to build all the gui he wants .
For this i also have some notes for you:
I have some dicussion with @void256 about why i have to expand nifty from 1.4 branch to support ControlEditing…
Nifty tangled the wire, it link to Java class via XML and expose the internal structure. In builder you dont have to make that dangerous movement. Some (a lot now) web framework to the reversed operation, specific the view within the control. So the java class should chose which screen it should link to. To do this, Nifty need a way to map Screen definition to controller class lazily.
I want a Control (then a Screen also) have a better “scope” other than “definition of nested element”. Because its come with scope of input and scope of variables, and scope of local styles… => for invidual and mixed, nested styles Control should have beter scope definition, at least in editing enviroment. For gui input testing and interactions (which current SDK NiftyEditor also lacked), the input scope also have to be limited, such as “just focused in this control” ignore all the call to outside.
The nifty xml loading is not open enough: what if nifty can survive exception about asset loading and retry (good for editing). This is my goal for the whole SDK also!
The eventbus are un appreciated. My editor also let the user pick element to generate the source code (event handling code) for specific inputs. Not talking about the code generation here but the event mechanism, the event mechnism depend in Id, which is not good. Id is just one kind of “selector”. While i have different selector, the eventbus should filter by those selector also and its a piece of cake really.
Other improvement are CSS and LESS and Groovy builder are optional.
I can share you part which is not affected by the changes in Nifty core, i think there are:
Control editing :
load the file
manage the Control in “normal” Nifty scope, so no advanced input, no advanced styles.
Find interactions and generate appropriate source code as ScreenController or Controller
Hi guys as I said in GSOC proposal I’m going to make some changes in my nifty-editor tool . In this week i want to code a better model and factory. I’m going to broke the dependency with xml element in nifty-editor model . Right now each GElement has his Dom element , this is quite bad and i did it so only for time beings. Also I want to delete Types class because it lives only to bind GElements to Dom elements and then build them from the factory .These changes will lead to some consequences in the code most are easy to solve other harder. The hardest two are : save the gui and load it . At the moment GuiReader and GuiWriter rely on xml element in GElemelt.class that made easy the entire process . Now i should find an other way to do it , my thoughts are :
GuiWriter : Implement visitor pattern iterate all over the elements and then save the document created . This is quite cool because the visitor pattern could be used also for other operation like style creation or even find the top element that contains a point .
GuiReader : the things become harder here . With the deletion of the Types class i can’t rely on GuiFactory . I need a way to bind GElement to xml element . Otherwise a way to bind ElementType from nifty-gui to GElement . I’m for the latter , @atomix suggested to use Guava plus Guice libraries . I don’t know this task deserve two more lib dependence , even if those libraries are quite porwellfull . My other implementation could be this : create a bindAnnotation that describes the binding between ElementType and GElement. Then create an Annotation processor and build a file with all the bindings . Finally runtime retrieve the list in a factory . This implementation doesn’t require any other dependency and fit well with the goal , even if is far less powerful .
My Nifty Editor is depended in Guice for testing purpose (it can unit test any GUI at design time!) and Guava for fluent sugar.
I also used Visitor for travelling the element tree for creating the CSS… But I don’t use it for read and write the XML! Here is my explanation for the design choice:
1 - I still keep the GElement tree beside of the Nifty element tree. The GElement has DOMElement, NiftyElement and NetbeanNode linked together, it keep sync of the three. It sounds like we do a lot of replicated classes but … indeed we have to!
[This called the failure of “strict” element tree] In this kind of element tree, the nodes are not treated similar, for ex: some can contains other, some not. The XML is checked the validation by its schema, NiftyElement also has a specific schema. So may be you want to write something like the Netbean XAM ( in which also replicate element tree) or you write it with your style and your libraries.
By the way, while parsing the XML, you keep just the piece of infomation you interested in (Maybe not the entire tree) you can also modify just that part of the tree also. Surprisingly, to merge two tree structure together is not a hard word.
I recommend you to use Common Digester to ease out the need of XML parsers… It flexible enough for all Nifty Screen file, Control file, Style and others. Its performance is not the top but it’s for design time, so it’s ok.
2- Binding between layers are quite a problem and I also recommend you to use another library BeanMapping (or the like).
Talking about using too much libraries. Yes, it save you time. And it’s also the philosophy of open-sourced anyway. But, JUST TRUST THE GOOD ONES!
Best regards,
Hope these suggestion have clean your mind from confusion a little bit,
yes a bit but it creates some others . To summarize a bit , first I should implement visitors pattern , don’t change the current Gelement/DomElement dependence and use Common Digester library to load and bind a gui . Thanks for the last advice i didn’t know about that library . About the dependence , I don’t think that is good for my editor . It’s good for the plugin thought.
Let me explain it a little more , notice those are my opinions and I respect yours , moreover i wanna to thank you for all your efforts. Keeping the trees in sinc is what the plug-in should do but the “library” ( my editor ) should be focus on wrap nifty-elements to edit them . Nifty-Editor model as a stand alone things shouldn’t be aware of how nifty-gui is saved and keep the domtree sinc only makes sense if you have a multiview like JME has . Finally what do you mean with Binding between layers ?? i didn’t get that part at all sorry .
Also if some other want to join to the discussion is welcome! @normen@void256
http://www.javacodegeeks.com/2013/10/java-object-to-object-mapper.html -> this… to copy attributes from GElement to Element etc. I used Orika to implement Nifty element Bean binding and Bean mapping ( so when you change the slider, the color change; in opposite, when you set the color, the slider change).
Hi guys! , model refactor is done! . What i added :
Types enum now is XmlTags and it’s only known in persistence package
Visitors pattern to add operations in GUI tree.
The model doesn’t depend to DOM elements
Gui is saved using jaxb and annotations .
Gui is loaded using a special factory that use a custom annotation
Most of mine choices was done mainly for a lack of time , there are a lot of other things more important to add so i decided for the fastest and better way .
Next up : Solving couple of issue that I’ve found this week ( also avaible on github ) and a question to @void256 How about dynamic layout ? I mean free the user to call layoutElements() but do it in automatic . Which are the challenges to add it to nifty-gui ? If you have some ideas i could give an hand to implement it .
p.s. In these days i found really fun to work with github and see how the JME’s community going on . I’d really keep help this great tool … as i can! ^^ .
@relucri said:
and a question to @void256 How about dynamic layout ? I mean free the user to call layoutElements() but do it in automatic . Which are the challenges to add it to nifty-gui ? If you have some ideas i could give an hand to implement it.
That might be possible to add.
I’m already doing that in Nifty 2.0 (which has currently a much simpler layouter which has less features than Nifty 1.x) where the layout is calculated on the fly when it is needed, e.g. when someone requests for instance the position or size of an element - in the best case this will be the renderer at the end =) But at the moment that’s all pretty much in development and 2.0 is far from being usable for even the most simple use cases.
Doing something similar for Nifty 1.x would be possible but it’s not as easy because the layouter is full of special cases and kinda more complicated. But in theory it should be doable. I’m just not sure how much trouble it will be
I’m currently trying to focus my work on the 1.4 related issues on the Nifty github issue tracker instead of working on 2.0 too. So this will delay 2.0 even more but 1.4 already got some nice user-contributed improvements lately like a better texture atlas manager and things like that. So for anything usable 1.4 would be the way to go for the foreseeable future.
All under the assumption that “real-life” allows me to work on it
Thanks @void256 for this detailed explanation! . As i said on twitter this feature is not mandatory for the editor because right now it can achieve a nice dynamic level without it . Yes it could save some time and make my editor code simpler , but it not worth the effort right now . Today I dig in nifty-gui code and i found some time to solve three issues I could give you an hand with 1.4 in this period ! About 2.0 I like the new code design , but i have a doubt , will it break the current file format ? I saw there’s no screen but only root nodes and NiftyNodes . When you have some spare time could you give some hints on how will be the structure of the gui ? just to prepare nifty-editor model to that changes .
Thanks again , Answer when you are free there’s no hurry.
Yeah, sure! But it’s too early! Don’t worry about 2.0 for now - really At the moment it’s all experimental and will probably still change quite a bit before anything will be usable. Preparing the editor for it is not necessary right now! Although I hope that it will make some of your editor life easier. But not right now.
And thanks for the pull request! I’ll take a look as soon as I can
I still think that make another visual component editor - aka the toolbar (beside of the properties bar) is preferable. The user just need to click the “Horizontal Align” button in the toolbar and his job is done. More over, he want to align bunch of buttons “Horizonal” at a time. The property panel is “weak” at this, as you should display multiple values and your editor code get mingled. The toolbar buttons is one concern at the time metaphor, and it’s also familiar with GUI designer.
.