Future GUI

Immortius

Lead Software Architect
Contributor
Architecture
GUI
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.
 

x3ro

Member
Contributor
GUI
I already started in my examples to give the JSON files different extensions:

Layout files: SomeMenu.layout

Style files: SomeMenu.style
Immortius miniME89
That doesn't make clear the underlying file format though (i.e. JSON). I like the double extension, e.g. .layout.json, but if I'm outvoted thats okay too :D
 

ddr2

New Member
Contributor
World
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 :thumbsup:
 

x3ro

Member
Contributor
GUI
ddr2: I didn't think about the editor syntax highlighting selection. So I say lets go with the double extension :) Any objections?
 

miniME89

GUI Lead
Contributor
GUI
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 :p) agree.
Still need to talk about:
  • 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?)
Just some points to get this discusses started again. Maybe Adeon has some additional thoughts ;)
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
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.
 

x3ro

Member
Contributor
GUI
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:

What are the features of each widget? So the code can be extended and adjusted to fit the needs.
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".

The base class of the Controller. What will the class include exactly?
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?
 

miniME89

GUI Lead
Contributor
GUI
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".

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.

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?
Me neither. If I find some time, I will write an example or something, where we can discussed some things.
 

Adeon

terasology.ru
Contributor
Architecture
GUI
Logistics
Maybe @Adeon has some additional thoughts
I have not ideas about it. But I think "setBackgroundColor(0x00, 0x00, 0x00, 0.75f);" is not good.
"setBackgroundColor("#FFFFFF");" is cool
 

Ten'son'

Member
Contributor
World
Or :
setBackgroundColor( Color col );

Color's constructors :
Color( "#FFFFFF" )
Color( 0x00, 0x00, 0x00, 0.75f )
etc.
 

x3ro

Member
Contributor
GUI
Adeon: That should be quite doable.
Ten'son': Thats problematic because you can't really create objects from the JSON style definition file, so a CSS-like hex color would be way easier to implement.
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
Gson lets you create objects from JSON definitions. :p

But whatever floats your boat.
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
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.
 

miniME89

GUI Lead
Contributor
GUI
I have not ideas about it. But I think "setBackgroundColor(0x00, 0x00, 0x00, 0.75f);" is not good.
"setBackgroundColor("#FFFFFF");" is cool

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.
 

miniME89

GUI Lead
Contributor
GUI
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

Member
Contributor
GUI
Ah, I hadn't seen that #339 had been merged in :) I will try to adapt my prototype ASAP and create a pull request for some improvement brainstorming / alpha testing :D
 

miniME89

GUI Lead
Contributor
GUI
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.
 

x3ro

Member
Contributor
GUI
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 :raritydespair:

Cervator? Kai Kratz? Immortius?
 
Top