There's actually no reason to end all these json files with .json, so you could even drop that. I'm not even sure why I went that way. Would certainly add clarity to end block definitions with .block, shape definitions with .shape and so forth.
Future GUI
- Thread starter Adeon
- Start date
Well, I vote for .layout.json / .style.json : easier to identify what the file does and what it contains. Plus, from what I know, many editors selects the right syntax highlighting using the file extension.
For only 5 more letters, I vote for the double extension
For only 5 more letters, I vote for the double extension
So guys, we should somehow get this to the next level.
- In my opinion we all agree on the structure of the layout file and style file. And File names will have double extension.
- Also the basic idea of the controller class we all (@x3ro and me ) agree.
- The base class of the Controller. What will the class include exactly?
- What are the features of each widget? So the code can be extended and adjusted to fit the needs.
- (The parser?)
What parser do you need? If you just mean for JSON, you should use Gson as it is already extensively used in Terasology (and pretty good besides). You have the option of either loading straight to a Java object or working directly with the JSON.
Immortius: I've been using "JsonSlurper" for my prototyping, which is built into Groovy. Hope thats okay too.
I am currently working on getting the prototype which you guys have already seen into Terasology, and making pretty good progress I think. UIDisplayWindows are already being created from the menu definition, including UIText elements
You can check out my progress here and tell me what you think.As to miniME89s questions:
The features of each widget are actually irrelevant for the system itself, as the system really only cares about some basic properties (such as the id) which every elements needs to have, but everything else is simply done through getters/setters. E.g. if an element has a "setText" method with a single argument, it has the property "text".
I haven't had much time to think about that, and I'm too tired to do it right now. Do you have any ideas on this already?
Yea, i am aware of this, but still, some features as positining elements by percentege isn't currently implemented, i will implement this the next days. And there are probably some other features we want, so we need to think about this.
And methodes like: setPosition(Vector2f pos). Should we change this to setPosition(float, float), since we are only able to deliver numbers through JSON, or will we "translate" float numbers into a Vector?
There is still stuff to discussed about the widgets, so they offer a clean and well designed interface right from the start, because changes there could result in changes in the JSON files.
Me neither. If I find some time, I will write an example or something, where we can discussed some things.
Immortius: I know, but you need a predefined structure for that, don't you? And the JSON style definitions don't really meet the criterionGson lets you create objects from JSON definitions.
But whatever floats your boat.
Hmm, yes and no. Obviously if you can produce a Java Bean that represents your style structure, then you can just ask Gson to read and write and that bean into and out of JSON and that will give you a default format. However you can plug in translators for different types, so if you'ld prefer Vector4f /Color variables to be loadable from [0, 0.5, 0.6, 0.2] and/or "#FFFFFF" you can write a small class to handle that.
If your outer-most section is "unstructured" in some way, you can create a class to fill in with the information and a translator that will manually handle reading the JSON. And then you'll be able to take advantage of GSON handing bean types and other types within that translator.
Although you might find your style definitions correspond to a Map<String, Style>, where Style is a structure of possible style fields.
If your outer-most section is "unstructured" in some way, you can create a class to fill in with the information and a translator that will manually handle reading the JSON. And then you'll be able to take advantage of GSON handing bean types and other types within that translator.
Although you might find your style definitions correspond to a Map<String, Style>, where Style is a structure of possible style fields.
I will overload the method, no problem
And I already started to expand the UIDisplayElement class to support such things as vertical/horizontal align, absolute/relative positioning.
I also have an idea for an easy implementation for a working z-order, because currently click events don't care about overlying display elements.
Should be finished the next days.
Just a quick message to keep all up to date on the progress:
- x3ro 's first draft of the parser works quite well, as you can see here: link
- My latest changes moved all the window creation to the GUIManager, which you can see here: link
I think if this would get merged together, it would already work
But still there is a lot of stuff to do, in the GUI itself and probably in x3ro's parser.
- x3ro 's first draft of the parser works quite well, as you can see here: link
- My latest changes moved all the window creation to the GUIManager, which you can see here: link
I think if this would get merged together, it would already work
But still there is a lot of stuff to do, in the GUI itself and probably in x3ro's parser.
x3ro my latest GUIManager changes are not merged in yet. I am waiting for the "Fixing Checkstyle" pull request to get merged in, than I will merge it with my branch.
I will also include some more changes, where I am currently working on. And there is still some ugly stuff where we need to get rid of.
But some "alpha testing" sounds good.
I will also include some more changes, where I am currently working on. And there is still some ugly stuff where we need to get rid of.
But some "alpha testing" sounds good.
miniME89 While rebasing I noticed that you made many class renames, which are okay ("UIDisplayWindow" -> "UIWindow", "UIGraphicsElement" -> "UIImage") but they make my work of rebasing my changes on top of yours much harder. Changes like naming, which are pretty much no-brainers (but introduce many merge conflicts), should be done when no one else is working on a new feature
And then I think that naming changes should not be made for the fun of it! In the case of "UIScrollableContainer" -> "UIDisplayContainerScrollable" I can not see any reason to rename the class, except for personal "gusto", which is especially annoying given the explanation above
Cervator? Kai Kratz? Immortius?
And then I think that naming changes should not be made for the fun of it! In the case of "UIScrollableContainer" -> "UIDisplayContainerScrollable" I can not see any reason to rename the class, except for personal "gusto", which is especially annoying given the explanation above
Cervator? Kai Kratz? Immortius?